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Abstract 


This document describes a way to perform the mapping between two 
signaling protocols: the Session Initiation Protocol (SIP) and the 
Integrated Services Digital Network (ISDN) User Part (ISUP) of 
Signaling System No. 7 (SS7). This mechanism might be implemented 
when using SIP in an environment where part of the call involves 
interworking with the Public Switched Telephone Network (PSTN). 
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1. Introduction 


SIP [1] is an application layer protocol for establishing, 
terminating and modifying multimedia sessions. It is typically 
carried over IP. Telephone calls are considered a type of multimedia 
sessions where just audio is exchanged. 


Integrated Services Digital Network (ISDN) User Part (ISUP) [12] is a 
level 4 protocol used in Signaling System No. 7 (SS7) networks. It 
typically runs over Message Transfer Part (MTP) although it can also 
run over IP (see SCTP [19]). ISUP is used for controlling telephone 
calls and for maintenance of the network (blocking circuits, 
resetting circuits etc.). 


A module performing the mapping between these two protocols is 
usually referred to as Media Gateway Controller (MGC), although the 
terms 'softswitch” or 'call agent’ are also sometimes used. An MGC 
has logical interfaces facing both networks, the network carrying 
ISUP and the network carrying SIP. The MGC also has some 
capabilities for controlling the voice path; there is typically a 
Media Gateway (MG) with El/T1 trunking interfaces (voice from Public 
Switched Telephone Network - PSTN) and with IP interfaces (Voice over 
IP - VoIP). The MGC and the MG can be merged together in one 
physical box or kept separate. 
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These MGCs are frequently used to bridge SIP and ISUP networks so 
that calls originating in the PSTN can reach IP telephone endpoints 
and vice versa. This is useful for cases in which PSTN calls need to 
take advantage of services in IP world, in which IP networks are used 
as transit networks for PSTN-PSTN calls, architectures in which calls 
originate on desktop ’softphones’ but terminate at PSTN terminals, 
and many other similar next-generation telephone architectures. 


This document describes logic and procedures which an MGC might use 
to implement the mapping between SIP and ISUP by illustrating the 
correspondences, at the message level and parameter level, between 
the protocols. It also describes the interplay between parallel 
state machines for these two protocols as a recommendation for 
implementers to synchronize protocol events in interworking 
architectures. 


2. Scope 


This document focuses on the translation of ISUP messages into SIP 
messages, and the mapping of ISUP parameters into SIP headers. For 
ISUP calls that traverse a SIP network, the purpose of translation is 
to allow SIP elements such as proxy servers (which do not typically 
understand ISUP) to make routing decisions based on ISUP criteria 
such as the called party number. This document consequently provides 
a SIP mapping only for those ISUP parameters which might be used by 
intermediaries in the routing of SIP requests. As a side effect of 
this approach, translation also increases the overall 
interoperability by providing critical information about the call to 
SIP endpoints that cannot understand encapsulated ISUP, or perhaps 
which merely cannot understand the particular ISUP variant 
encapsulated in a message. 


This document also only takes into account the call functionality of 
ISUP. Maintenance messages dealing with PSTN trunks are treated only 
as far as they affect the control of an ongoing call; otherwise these 
messages neither have nor require any analog in SIP. 


Messages indicating error or congestion situations in the PSTN (MTP- 
3) and the recovery mechanisms used such as User Part Available and 
User Part Test ISUP messages are outside the scope of this document 


There are several flavors of ISUP. International Telecommunication 
Union Telecommunication Standardization Sector (ITU-T) International 
ISUP [12] is used through this document; some differences with the 
American National Standards Institute (ANSI) [11] ISUP and the 
Telecommunication Technology Committee (TTC) ISUP are also outlined. 
ITU-T ISUP is used in this document because it is the most widely 
known of all the ISUP flavors. Due to the small number of fields 
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that map directly from ISUP to SIP, the signaling differences between 
ITU-T ISUP and specific national variants of ISUP will generally have 
little to no impact on the mapping. Note, however, that the ITU-T 
has not substantially standardized practices for Local Number 
Portability (LNP) since portability tends to be grounded in national 
numbering plan practices, and that consequently LNP must be described 
on a virtually per-nation basis. The number portability practices 
described in this document are presented as an optional mechanism. 


Mapping of SIP headers to ISUP parameters in this document focuses 
largely on the mapping between the parameters found in the ISUP 
Initial Address Message (IAM) and the headers associated with the SIP 
INVITE message; both of these messages are used in their respective 
protocols to request the establishment of a call. Once an INVITE has 
been sent for a particular session, such headers as the To and From 
field become essentially fixed, and no further translation will be 
required during subsequent signaling, which is routed in accordance 
with Via and Route headers. Hence, the problem of parameter-to- 
header mapping in SIP-T is confined more or less to the IAM and the 
INVITE. Some additional detail is given in the population of 
parameters in the ISUP messages Address Complete Message (ACM) and 
Release Message (REL) based on SIP status codes. 


This document describes when the media path associated with a SIP 
call is to be initialized, terminated, modified, etc., but it does 
not go into details such as how the initialization is performed or 
which protocols are used for that purpose. 


3. Terminology 


In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 
described in RFC2119 [2] and indicate requirement levels for 
compliant SIP implementations. 


4. Scenarios 


There are several scenarios where ISUP-SIP mapping takes place. The 
way the messages are generated is different depending on the 
scenario. 
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When there is a single MGC and the call is from a SIP phone to a PSTN 
phone, or vice versa, the MGC generates the ISUP messages based on 
the methods described in this document. 


4+------------- + 4+----- + 4+------------- + 
PSTN switch +------- + MGC +------- + SIP UAC/UAS | 
4+------------- + 4+----- + 4+------------- + 


The scenario where a call originates in the PSTN, goes into a SIP 
network and terminates in the PSTN again is known as "SIP bridging". 
SIP bridging should provide ISUP transparency between the PSTN 
switches handling the call. This is achieved by encapsulating the 
incoming ISUP messages in the body of the SIP messages (see [3]). In 
this case, the ISUP messages generated by the egress MGC are the ones 
present in the SIP body (possibly with some modifications; for 
example, if the called number in the request Uniform Resource 
Identifier - URI - is different from the one present in the ISUP due 
to SIP redirection, the ISUP message will need to be adjusted). 


4+------ + 4+------------- + +----- + 4+------------ + 4+------ + 
PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN | 
+------ + 4+------------- + 4+----- + 4+------------ + 4+------ + 


SIP is used in the middle of both MGCs because the voice path has to 
be established through the IP network between both MGs; this 
structure also allows the call to take advantage of certain SIP 
services. ISUP messages in the SIP bodies provide further 
information (such as cause values and optional parameters) to the 
peer MGC. 


In both scenarios, the ingress MGC places the incoming ISUP messages 
in the SIP body by default. Note that this has security 
implications; see Section 15. If the recipient of these messages 
(typically a SIP User Agent Client/User Agent Server - UAC/UAS) does 
not understand them, a negotiation using the SIP ’Accept’ and 
‘Require’ headers will take place and they will not be included in 
the next SIP message exchange. 


There can be a Signaling Gateway (SG) between the PSTN and the MGC. 
It encapsulates the ISUP messages over IP in a manner such as the one 
described in [19]. The mapping described in this document is not 
affected by the underlying transport protocol of ISUP. 


Note that overlap dialing mechanisms (use of the Subsequent Address 
Message - SAM) are outside the scope of this document. This document 
assumes that gateways facing ISUP networks in which overlap dialing 
is used will implement timers to insure that all digits have been 
collected before an INVITE is transmitted to a SIP network. 
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In some instances, gateways may receive incomplete ISUP messages 
which indicate message segmentation due to excessive message length. 
Commonly these messages will be followed by a Segmentation Message 
(SGM) containing the remainder of the original ISUP message. An 
incomplete message may not contain sufficient parameters to allow for 
a proper mapping to SIP; similarly, encapsulating (see below) an 
incomplete ISUP message may be confusing to terminating gateways. 
Consequently, a gateway MUST wait until a complete ISUP message is 
received (which may involve waiting until one or more SGMs arrive) 
before sending any corresponding INVITE. 


5. SIP Mechanisms Required 


For a correct mapping between ISUP and SIP, some SIP mechanisms above 
and beyond those available in the base SIP specification are needed. 
These mechanisms are discussed below. If the SIP UAC/UAS involved in 
the call does not support them, it is still possible to proceed, but 
the behavior in the establishment of the call may be slightly 
different than that expected by the user (e.g., other party answers 
before receiving the ringback tone, user is not informed about the 
call being forwarded, etc.). 


5.1 'Transparent” Transit of ISUP Messages 


To allow gateways to take advantage of the full range of services 
afforded by the existing telephone network when placing calls from 
PSTN to PSTN across a SIP network, SIP messages MUST be capable of 
transporting ISUP payloads from gateway to gateway. The format for 
encapsulating these ISUP messages is defined in [3]. 


SIP user agents which do not understand ISUP are permitted to ignore 
these optional MIME bodies. 


5.2 Understanding MIME Multipart Bodies 
In most PSTN interworking situations, SIP message bodies will be 
required to carry session information (Session Description Protocol - 
SDP) in addition to ISUP and/or billing information. 
PSTN interworking nodes MUST understand the MIME type of 


"multipart/mixed" as defined in RFC2046 [4]. Clients express support 
for this by including "multipart/mixed" in an "Accept" header. 
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5.3 Transmission of Dual-Tone Multifrequency (DIMF) Information 


How DTMF tones played by the user are transmitted by a gateway is 
completely orthogonal to how SIP and ISUP are interworked; however, 
as DIMF carriage is a component of a complete gatewaying solution 
some guidance is offered here. 


Since the codec selected for voice transmission may not be ideally 
suited for carrying DIMF information, a symbolic method of 
transmitting this information in-band is desirable (since out-of-band 
transmission alone would provide many challenges for synchronization 
of the media stream for tone re-insertion). This transmission MAY be 
performed as described in RFC2833 [5]. 


5.4 Reliable Transmission of Provisional Responses 


Provisional responses (in the 1xx class) are used in the transmission 
of call progress information. PSTN interworking in particular relies 
on these messages for control of the media channel and timing of call 
events. 


When interworking with the PSTN, SIP messages MUST be sent reliably 
end-to-end; reliability of requests is guaranteed by the base 
protocol. One application-layer provisional reliability mechanism 
for responses is described in [18]. 


5.5 Early Media 


Early media denotes the capability to play media (audio for 
telephony) before a SIP session has been established (before a 2xx 
response code has been sent). For telephony, establishment of media 
in the backwards direction is desirable so that tones and 
announcements can be played, especially when interworking with a 
network that cannot signal call status out of band (such as a legacy 
MF network). In cases where interworking has not been encountered, 
use of early media is almost always undesirable since it consumes 
inter-machine trunk recourses to play media for which no revenue is 
collected. Note that since an INVITE almost always contains the SDP 
required to send media in the backwards direction, and requires that 
user agents prepare themselves to receive backwards media as soon as 
an INVITE transmitted, the baseline SIP protocol has enough support 
to enable rudimentary unidirectional early media systems. However, 
this mechanism has a number of limitations - for example, media 
streams offered in the SDP of the INVITE cannot be modified or 
declined, and bidirectional RTCP required for session maintenance 
cannot be established. 
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Therefore gateways MAY support more sophisticated early media systems 
as they come to be better understood. One mechanism that provides a 
way of initiating a fully-featured early media system is described in 
[20]. 


Note that in SIP networks not just switches but also user agents can 
generate the 18x response codes and initiate early backwards media, 
and that therefore some gateways may wish to enforce policies that 
restrict the use of backwards media from arbitrary user agents (see 
Section 15). 


5.6 Mid-Call Transactions which do not change SIP state 


When interworking with the PSTN, there are situations when gateways 
will need to send messages to each other over SIP that do not 
correspond to any SIP operations. 


In support of mid-call transactions and other ISUP events that do not 
correspond to existing SIP methods, SIP gateways MUST support the 
INFO method, defined in RFC2976 [6]. Note that this document does 
not prescribe or endorse the use of INFO to carry DIMF digits. 


Gateways MUST accept "405 Method Not Allowed" and "501 Not 
Implemented" as non-fatal responses to INFO requests - that is, any 
call in progress MUST NOT be torn down if a destination so rejects an 
INFO request sent by a gateway. 


5.7 Privacy Protection 


ISUP has a concept of presentation restriction - a mechanism by which 
a user can specify that they would not like their telephone number to 
be displayed to the person they are calling (presumably someone with 
Caller ID). When a gateway receives an ISUP request that requires 
presentation restriction, it must therefore shield the identity of 
the caller in some fashion. 


The base SIP protocol supports a method of specifying that a user is 
anonymous. However, this system has a number of limitations - for 
example, it reveals the identity of the gateway itself, which could 
be a privacy-impacting disclosure. Therefore gateways MAY support 
more sophisticated privacy systems. One mechanism that provides a 
way of supporting fully-featured privacy negotiation (which interacts 
well with identity management systems) is described in [9B]. 
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5.8 CANCEL causes 


There is a way in ISUP to signal that you would like to discontinue 
an attempt to set up a call - the general-purpose REL is sent in the 
forwards direction. There is a similar concept in SIP - that of a 
CANCEL request that is sent in order to discontinue the establishment 
of a SIP dialog. For various reasons, however, CANCEL requests 
cannot contain message bodies, and therefore in order to carry the 
important information in the REL (the cause code) end-to-end in sip 
bridging cases, ISUP encapsulation cannot be used. 


Ordinarily, this is not a big problem, because for practical purposes 
the only reason that a REL is ever issued to cancel a call setup 
attempt is that a user hangs up the phone while it is still ringing 
(which results in a "Normal clearing" cause code). However, under 
exceptional conditions, like catastrophic network failure, a REL may 
be sent with a different cause code, and it would be handy if a SIP 
network could carry the cause code end-to-end. Therefore gateways 
MAY support a mechanism for end-to-end delivery of such failure 
reasons. One mechanism that provides this capability is described in 
[9]. 


6. Mapping 


The mapping between ISUP and SIP is described using call flow 
diagrams and state machines. One state machine handles calls from 
SIP to ISUP and the second from ISUP to SIP. There are details, such 
as some retransmissions and some states (waiting for the Release 
Complete Message - RLC, waiting for SIP ACK etc.), that are not shown 
in the figures in order to make them easier to follow. 


The boxes represent the different states of the gateway, and the 
arrows show changes in the state. The event that triggers the change 
in the state and the actions to take appear on the arrow: event / 
section describing the actions to take. 


For example, ’INVITE / 7.2.1’ indicates that an INVITE request has 
been received by the gateway, and the procedure upon reception is 
described in the section 7.2.1 of this document. 


It is RECOMMENDED that gateways implement functional equivalence with 
the call flows detailed in Section 7.1 and Section 8.1. Deviations 
from these flows are permissible in support of national ISUP 
variants, or any of the conservative policies recommended in Section 
15. 
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7. SIP to ISUP Mapping 
7.1 SIP to ISUP Call flows 


The following call flows illustrate the order of messages in typical 
success and error cases when setting up a call initiated from the SIP 
network. "100 Trying" acknowledgements to INVITE requests are not 
displayed below although they are required in many architectures. 


In these diagrams, all call signaling (SIP, ISUP) is going to and 
from the MGC; media handling (e.g., audio cut-through, trunk freeing) 
is being performed by the MG, under the control of the MGC. For the 
purpose of simplicity, these are shown as a single node, labeled 
"MGC/MG." 


7.1.1 En-bloc Call Setup (no auto-answer) 


SIP MGC/MG PSTN 
1 | --------- INVITE---------- > | | 
| <---------- 100------------ | | 
| |------------ IAM---------- >|2 
< Audio 
| <----------- ACM----------- E 
4 | <---------- 18x------------ | | 
| <========= Audi 0o=========== | | 
| |<----------- CPG----------- |5 
6 | <---------- 18x------------ | | 
LST ANM-=========-=- 7 
| < Audio > 
8 | <---------- 200------------ | | 
| <========= Audio========== >| 
9 | ----------- ACK----------- > | | 
1. When a SIP user wishes to begin a session with a PSTN user, the 


SIP node issues an INVITE request. 


2. Upon receipt of an INVITE request, the gateway maps it to an IAM 
message and sends it to the ISUP network. 


3. The remote ISUP node indicates that the address is sufficient to 
set up a call by sending back an ACM message. 


4. The "called party status" code in the ACM message is mapped to a 
SIP provisional response (as described in Section 7.2.5 and 


Section 7.2.6) and returned to the SIP node. This response may 
contain SDP to establish an early media stream (as shown in the 
diagram). If no SDP is present, the audio will be established in 


both directions after step 8. 


Camarillo, et. al. Standards Track [Page 11] 


RFC 3398 ISUP to SIP Mapping November 2002 


If the ISUP variant permits, the remote ISUP node may issue a 
variety of Call Progress (CPG) messages to indicate, for example, 
that the call is being forwarded. 


Upon receipt of a CPG message, the gateway will map the event 
code to a SIP provisional response (see Section 7.2.9) and send 
it to the SIP node. 


Once the PSTN user answers, an Answer (ANM) message will be sent 
to the gateway. 


Upon receipt of the ANM, the gateway will send a 200 message to 
the SIP node. 


The SIP node, upon receiving an INVITE final response (200), will 
send an ACK to acknowledge receipt. 


7.1.2 Auto-answer Call setup 


SIP MGC /MG PSTN 
1 | --------- INVITE---------- > | 
<---------- 100------------ | 
~----------- IAM---------->|2 
| |< Audio | 
| |<----------- CON----------- |3 
| |< Audio >| 
4|<---------- 200------------ | | 
<========= Audi o========== > 
5 | ----------- ACK----------- > 


Note that this flow is not supported in ANSI networks. 


1. 


When a SIP user wishes to begin a session with a PSTN user, the 
SIP node issues an INVITE request. 


Upon receipt of an INVITE request, the gateway maps it to an IAM 
message and sends it to the ISUP network. 


Since the remote node is configured for automatic answering, it 
will send a Connect Message (CON) upon receipt of the IAM. (For 
ANSI, this message will be an ANM). 


Upon receipt of the CON, the gateway will send a 200 message to 
the SIP node. 


The SIP node, upon receiving an INVITE final response (200), will 
send an ACK to acknowledge receipt. 
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7.1.3 ISUP T7 Expires 


SIP MGC/MG PSTN 


| |< Audio 
| | *** T7 Expires *** 
** MG Releases PSTN Trunk ** 


4|<---------- 504------------ | ------------ REL---------- >|3 
5 | ----------- ACK----------- > | | 
1. When a SIP user wishes to begin a session with a PSTN user, the 


SIP node issues an INVITE request. 

2. Upon receipt of an INVITE request, the gateway maps it to an IAM 
message and sends it to the ISUP network. The ISUP timer T7 is 
started at this point. 


3. The ISUP timer T7 expires before receipt of an ACM or CON 
message, so a REL message is sent to cancel the call. 


4. A gateway timeout message is sent back to the SIP node. 


5. The SIP node, upon receiving an INVITE final response (504), will 
send an ACK to acknowledge receipt. 
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7.1.4 SIP Timeout 


SIP MGC/MG PSTN 

1 | --------- INVITE -----=-=-=-=-- > | | 
| <---------- 100------------ | | 

| |------------ IAM---------- >|2 
| |< Audio | 

| |<----------- CON----------- |3 
< Audio > 

E S A 200------------ 
| *** Tl Expires *** | | 
|<---------- 200------------ | | 
| *** Tl Expires *** | | 
|<---------- 200------------ | | 
| *** Tl Expires *** | | 
<---------- 200------------ | 
*x* Tl Expires *** | 

| <---------- 200------------ | | 
| *** Tl Expires *** | | 
|<---------- 200------------ | | 
| *** Tl Expires *** | | 
5 | <---------- 200------------ | 
| 

7 | <---------- BYE------------ | ------------ REL---------- >|6 

| |<----------- RLC----------- |8 

1. When a SIP user wishes to begin a session with a PSTN user, the 


SIP node issues an INVITE request. 


2. Upon receipt of an INVITE request, the gateway maps it to an IAM 
message and sends it to the ISUP network. 


3. Since the remote node is configured for automatic answering, it 
will send a CON message upon receipt of the IAM. In ANSI flows, 
rather than a CON, an ANM (without ACM) would be sent. 


4. Upon receipt of the ANM, the gateway will send a 200 message to 
the SIP node and set SIP timer Tl. 


5. The response is retransmitted every time the SIP timer T1 
expires. 


6. After seven retransmissions, the call is torn down by sending a 


REL to the ISUP node, with a cause code of 102 (recover on timer 
expiry). 
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7. A BYE is transmitted to 
call. Further handling 
SIP node’s state is not 


8. Upon receipt of the REL 
with an RLC message. 


7.1.5 ISUP Setup Failure 


to SIP Mapping November 2002 


the SIP node in an attempt to close the 
for this clean up is not shown, since the 
easily known in this scenario. 


message, the remote ISUP node will reply 


SLP MGC/MG PSTN 

1|--------- INVITE---------- >| | 
|<---------- 100------------ | | 
| |------------ IAM---------- >|2 
| |<----------- REL----------- |3 
| |------------ RLC---------- >|4 

E 4xx+----------- 

6 | ----------- ACK----------- > 

1. When a SIP user wishes to begin a session with a PSTN user, the 


SIP node issues an INVITE request. 


2. Upon receipt of an INVITE request, the gateway maps it to an IAM 


message and sends it to 


the ISUP network. 


3. Since the remote ISUP node is unable to complete the call, it 


will send a REL. 


4. The gateway releases the circuit and confirms that it is 
available for reuse by sending an RLC. 


5. The gateway translates the cause code in the REL to a SIP error 


response (see Section 7. 


2.4) and sends it to the SIP node. 


6. The SIP node sends an ACK to acknowledge receipt of the INVITE 


final response. 
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7.1.6 Cause Present in ACM Message 


STP MGC/MG PSTN 
1|--------- INVITE---------- >| | 
|<---------- 100------------ | | 
| |------------ IAM---------- >|2 
| |< Audio | 
| |<---ACM with cause code---|3 
4|<------ 183 with SDP------- 
<========= Audi o=========== 
** Interwork timer expires ** 
5|< sants Axx+== == 3522255 | | 
| |------------ REL---------- >|6 
| |<----------- RLC----------- |7 
8 | ----------- ACK----------- > | | 
1. When a SIP user wishes to begin a session with a PSTN user, 


SIP node issues an INVITE request. 


the 


2. Upon receipt of an INVITE request, the gateway maps it to an IAM 


message and sends it to the ISUP network. 


3. Since the ISUP node is unable to complete the call and wants to 
generate the error tone/announcement itself, it sends an ACM with 
a cause code. The gateway starts an interwork timer. 

4. Upon receipt of an ACM with cause (presence of the CAI 


parameter), the gateway will generate a 183 message towards 


the 


SIP node; this contains SDP to establish early media cut-through. 


5. A final INVITE response, based on the cause code received in the 
earlier ACM message, is generated and sent to the SIP node to 


terminate the call. See Section 7.2.4.1 for the table which 


contains the mapping from cause code to SIP response. 


6. Upon expiration of the interwork timer, a REL is sent towards the 
PSTN node to terminate the call. Note that the SIP node can also 
terminate the call by sending a CANCEL before the interwork timer 
expires. In this case, the signaling progresses as in Section 


pee lene a 


7. Upon receipt of the REL message, the remote ISUP node will reply 


with an RLC message. 


8. The SIP node sends an ACK to acknowledge receipt of the INVITE 


final response. 
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7.1.7 Call Canceled by SIP 


SIP MGC /MG PSTN 
1 | --------- INVITE---------- > | | 
| <---------- 100------------ | | 
| |------------ IAM---------- >|2 
| |< Audio | 
| |<----------- ACM----------- |3 
4 | <---------- 18x------------ | 
<========= Audi o=========== 
| ** MG Releases IP Resources ** 
5 | ---------- CANCEL--------- > | | 
6|<---------- 200------------ | | 
| ** MG Releases PSTN Trunk ** 
| | ------------ REL---------- >|7 
8 | <---------- 487------------ 
<----------- RLC----------- le 
10 | ----------- ACK----------- > | | 


When a SIP user wishes to begin a session with a PSTN user, the 
SIP node issues an INVITE request. 


Upon receipt of an INVITE request, the gateway maps it to an IAM 
message and sends it to the ISUP network. 


The remote ISUP node indicates that the address is sufficient to 
set up a call by sending back an ACM message. 


The "called party status" code in the ACM message is mapped to a 
SIP provisional response (as described in Section 7.2.5 and 
Section 7.2.6) and returned to the SIP node. This response may 
contain SDP to establish an early media stream. 


To cancel the call before it is answered, the SIP node sends a 
CANCEL request. 


The CANCEL request is confirmed with a 200 response. 


Upon receipt of the CANCEL request, the gateway sends a REL 
message to terminate the ISUP call. 


The gateway sends a "487 Call Cancelled" message to the SIP node 
to complete the INVITE transaction. 


Upon receipt of the REL message, the remote ISUP node will reply 
with an RLC message. 
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10. Upon receipt of the 487, the SIP node will confirm reception 
with an ACK. 
7.2 State Machine 


Note that REL can be received in any state; the handling is the same 
for each Case (see Section 10). 


| 
| 
| 
| | 
| T7/6.2.2  +=----------------—---—---—-— + REL/6.2.4 | 
a + Trying LASTRA RS >+ 
| Ho ho Yoo Ho + | 
| CANCEL/6.2.3 | | | | | 
4$<---------------- + | E.ACM/ | ACM/ | CON/ANM 
| Ma, see ann (I eae, | 
| v | | | 
| T9/6.2.8 +-------------- + 
+<---------- + Not alerting | 
| ae eos at | | 
| CANCEL/6.2.3 | | | | | 
|<-------------- + | CPG/ | | 
| | 6.2.9 | | | 
V vV 
T9/6.2.8 +--------------- + REL/6.2.4 
ii + Alerting | - | Soma eae ees > | 
| <---------------- 4--4----- prsi + | | 
| CANCEL/6.2.3 lg oar. | 
| cPG/ | | | ANM/ | | 
| 6.2.9 +--+ | 6.2.7 | | 
Vv Vv 
| Ho + REL/9.2 | 
| | Waiting for ACK | SER TARA > | 
| Ho $----------- + | 
| | 
| | ACK/6.2.10 | 
Vv 
| BYE/9.1 Ho + REL/9.2 | 
+<------------- + Connected HET SSS >+ 
4------------------------- + 
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7.2.1 INVITE received 


When an INVITE request is received by the gateway, a "100 Trying" 
response MAY be sent back to the SIP network indicating that the 
gateway is handling the call. 


The necessary hardware resources for the media stream MUST be 
reserved in the gateway when the INVITE is received, since an IAM 
message cannot be sent before the resource reservation (especially 
TCIC selection) takes place. Typically the resources consist of a 
time slot in an El/T1 and an RTP/UDP port on the IP side. Resources 
might also include any quality-of-service provisions (although no 
such practices are recommended in this document). 


After sending the IAM the timer T7 is started. The default value of 
T7 is between 20 and 30 seconds. The gateway goes to the 'Trying' 
state. 


7.2.1.1 INVITE to IAM procedures 


This section details the mapping of the SIP headers in an INVITE 
message to the ISUP parameters in an Initial Address Message (IAM). 
A PSTN-SIP gateway is responsible for creating an IAM when it 
receives an INVITE. 


Five mandatory parameters appear within the IAM message: the Called 
Party Number (CPN), the Nature of Connection Indicator (NCI), the 
Forward Call Indicators (FCI), the Calling Party’s Category (CPC), 
and finally a parameter that indicates the desired bearer 


characteristics of the call - in some ISUP variants the Transmission 
Medium Requirement (TMR) is required, in others the User Service 
Information (USI) (or both). All IAM messages MUST contain these 
five parameters at a minimum. Thus, every gateway must have a means 


of populating each of those five parameters when an INVITE is 
received. Many of the values that will appear in these parameters 
(such as the NCI or USI) will most likely be the same for each IAM 
created by the gateway. Others (such as the CPN) will vary ona 
call-by-call basis; the gateway extracts information from the INVITE 
in order to properly populate these parameters. 


There are also quite a few optional parameters that can appear in an 
IAM message; 0.763 [17] lists 29 in all. However, each of these 
parameters need not to be translated in order to achieve the goals of 
SIP-ISUP mapping. As is stated above, translation allows SIP network 
elements to understand the basic PSTN context of the session (who it 
is for, and so on) if they are not capable of deciphering any 
encapsulated ISUP. Parameters that are only meaningful to the PSTN 
will be carried through PSTN-SIP- PSTN networks via encapsulation - 
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translation is not necessary for these parameters. Of the 
aforementioned 29 optional parameters, only the following are 
immediately useful for translation: the Calling Party’s Number (CIN, 
which is commonly present), Transit Network Selection (TNS), Carrier 
Identification Parameter (CIP, present in ANSI networks), Original 
Called Number (OCN), and the Generic Digits (known in some variants 
as the Generic Address Parameter (GAP)). 


When a SIP INVITE arrives at a PSTN gateway, the gateway SHOULD 
attempt to make use of encapsulated ISUP (see [3]), if any, within 
the INVITE to assist in the formulation of outbound PSTN signaling, 
but SHOULD also heed the security considerations in Section 15. If 
possible, the gateway SHOULD reuse the values of each of the ISUP 
parameters of the encapsulated IAM as it formulates an IAM that it 
will send across its PSTN interface. In some cases, the gateway will 
be unable to make use of that ISUP - for example, if the gateway 
cannot understand the ISUP variant and must therefore ignore the 
encapsulated body. Even when there is comprehensible encapsulated 
ISUP, the relevant values of SIP header fields MUST ‘’overwrite’ 
through the process of translation the parameter values that would 
have been set based on encapsulated ISUP. In other words, the 
updates to the critical session context parameters that are created 
in the SIP network take precedence, in ISUP-SIP-ISUP bridging cases, 
over the encapsulated ISUP. This allows many basic services, 
including various sorts of call forwarding and redirection, to be 
implemented in the SIP network. 


For example, if an INVITE arrives at a gateway with an encapsulated 
IAM with a CPN field indicating the telephone number +12025332699, 
but the Request-URI of the INVITE indicates 'tel:+15105550110', the 
gateway MUST use the telephone number in the Request-URI, rather than 
the one in the encapsulated IAM, when creating the IAM that the 
gateway will send to the PSTN. Further details of how SIP header 
fields are translated into ISUP parameters follow. 


Gateways MUST be provisioned with default values for mandatory ISUP 
parameters that cannot be derived from translation(such as the NCI or 
TMR parameters) for those cases in which no encapsulated ISUP is 
present. The FCI parameter MUST also have a default, as only the ’M’ 
bit of the default may be overwritten during the process of 
translation if the optional number portability translation mechanisms 
described below are used. 


The first step in the translation of the fields of an INVITE message 
to the parameters of an IAM is the inspection of the Request-URI. 
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If the optional number portability practices are supported by the 
gateway, then the following steps related to handling of the 'npdi'” 
and ’rn’ parameters of the Request-URI should be followed. 


If there is no 'npdi=yes” field within the Request-URI, then the 
primary telephone number in the tel URL (the digits immediately 
following ’tel:’) MUST be converted to ISUP format, following the 
procedures described in Section 12, and used to populate the CPN 
parameter. 


If the ’npdi=yes’ field exists in the Request-URI, then the FCI 
parameter bit for 'number translated” within the IAM MUST reflect 
that a number portability dip has been performed. 


If in addition to the ’npdi=yes’ field there is no 'rn=" field 
present, then the main telephone number in the tel URL MUST be 
converted to ISUP format (see Section 12) and used to populate the 
CPN parameter. This indicates that a portability dip took place, but 
that the called party’s number was not ported. 


If in addition to the ’npdi=yes’ field an ’rn=’ field is present, 
then in ANSI ISUP the 'rn=” field MUST be converted to ISUP format 
and used to populate the CPN. The main telephone number in the tel 
URL MUST be converted to ISUP format and used to populate the Generic 
Digits Parameter (or GAP in ANSI). In some other ISUP variants, the 
number given in the 'rn=" field would instead be prepended to the 
main telephone number (with or without a prefix or separator) and the 
combined result MUST be used to populate the CPN. Once the ’rn=’ and 
‘'npdi=’ parameters have been translation, the number portability 
translation practices are complete. 


The following mandatory translation practices are performed after 
number portability translations, if any. 


If number portability practices are not supported by the gateway, 
then the primary telephone number in the tel URL (the digits 
immediately following ’tel:’) MUST be converted to ISUP format, 
following the procedures described in Section 12, and used to 
populate the CPN parameter. 


If the primary telephone number in the Request-URI and that of the To 
header are at variance, then the To header SHOULD be used to populate 
an OCN parameter. Otherwise the To header SHOULD be ignored. 


Some optional translation procedures are provided for carrier-based 
routing. If the 'cic=" parameter is present in the Request-URI, the 
gateway SHOULD consult local policy to make sure that it is 
appropriate to transmit this Carrier Identification Code (CIC, not to 
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be confused with the MTP3 ’circuit identification code’) in the IAM; 
if the gateway supports many independent trunks, it may need to 
choose a particular trunk that points to the carrier identified by 
the CIC, or a tandem through which that carrier is reachable. 
Policies for such trunks (based on the preferences of the carriers 
with which the trunks are associated and the ISUP variant in use) 
SHOULD dictate whether the CIP or TNS parameter is used to carry the 
CIC. In the absence of any pre-arranged policies, the TNS should be 
used when the CPN parameter is in an international format (i.e., the 
tel URL portion of the Request-URI is preceded by a ’+’, which will 
generate a CPN in international format), and (where supported) the 
CIP should be used in other cases. 


When a SIP call has been routed to a gateway, then the Request-URI 
will most likely contain a tel URL (or a SIP URI with a tel URL user 
portion) - SIP-ISUP gateways that receive Request-URIs that do not 
contain valid telephone numbers SHOULD reject such requests with an 
appropriate response code. Gateways SHOULD however continue to 
process requests with a From header field that does not contain a 
telephone number, as will sometimes be the case if a call originated 
at a SIP phone that employs a SIP URI user@host convention. The CIN 
parameter SHOULD be omitted from the outbound IAM if the From field 
is unusable. Note that as an alternative, gateway implementers MAY 
consider some non-standard way of mapping particular SIP URIs to 
telephone numbers. 


When a gateway receives a message with (comprehensible) encapsulated 
ISUP, it MUST set the FCI indicator in the generated IAM so that all 
interworking-related bits have the same values as their counterparts 
in the encapsulated ISUP. In most cases, these indicators will state 
that no interworking was encountered, unless interworking has been 
encountered somewhere else in the call path. If usable encapsulated 
ISUP is not present in an INVITE received by the gateway, it is 
STRONGLY RECOMMENDED that the gateway set the Interworking Indicator 
bit of the FCI to 'no interworking’ and the ISDN User Part Indicator 
to ’ISUP used all the way’; the gateway MAY also set the Originating 
Access indicator to 'Originating access non-ISDN’ (generally, it is 
not safe to assume that SIP phones will support ISDN endpoint 
services, and the procedures in this document do not detail mappings 
to translate all such services). 


Note that when ’interworking encountered’ is set in the FCI parameter 
of the IAM, this indicates that ISUP is interworking with a network 
which is not capable of providing as many services as ISUP does. 

ISUP networks will therefore not employ certain features they 
otherwise normally would, including potentially the use of ISDN cause 
codes in failure conditions (as opposed to sending ACMs followed by 
audible announcements). If desired, gateway vendors MAY provide a 


Camarillo, et. al. Standards Track [Page 22] 


RFC 3398 ISUP to SIP Mapping November 2002 


configurable option, usable at the discretion of service providers, 
that will signal in the FCI that interworking has been encountered 
(and that ISUP is not used all the way) when encapsulated ISUP is not 
present; however, doing so may significantly limit the efficiency and 
transparency of SIP-ISUP translation. 


Claiming to be an ISDN node might make the callee request ISDN user 


to user services. Since user to user services 1 and 2 must be 
requested by the caller, they do not represent a problem (see [14]). 
User to user service 3 can be requested by the callee also. In non- 


SIP bridging situations, the MGC should be capable of rejecting this 
service request. 


7.2.2 ISUP T7 expires 


Since no response was received from the PSTN all the resources in the 
MG are released. A '504 Server Timeout’ SHOULD be sent back to the 
SIP network. A REL message with cause value 102 (protocol error, 
recovery on timer expiry) SHOULD be sent to the PSTN. Gateways can 
expect the PSTN to respond with RLC and the SIP network to respond 
with an ACK indicating that the release sequence has been completed. 


7.2.3 CANCEL or BYE received 


If a CANCEL or BYE request is received before a final SIP response 
has been sent, a ’200 OK’ MUST be sent to the SIP network to confirm 
the CANCEL or BYE; a 487 MUST also be sent to terminate the INVITE 
transaction. All the resources are released and a REL message SHOULD 
be sent to the PSTN with cause value 16 (normal clearing). Gateways 
can expect an RLC from the PSTN to be received indicating that the 
release sequence is complete. 


In SIP bridging situations, a REL might be encapsulated in the body 
of a BYE request. Although BYE is usually mapped to cause code 16 
(normal clearing), under exceptional circumstances the cause code in 
the REL message might be different. Therefore the Cause Indicator 
parameter of the encapsulated REL should be re-used in the REL sent 
to the PSTN. 


Note that a BYE or CANCEL request may contain a Reason header that 
SHOULD be mapped to the Cause Indicator parameter (see Section 5.8). 
If a BYE contains both a Reason header and encapsulated ISUP, the 
value in the Reason header MUST be preferred. 


All the resources in the gateway SHOULD be released before the 
gateway sends any REL message. 
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7.2.4 REL received 


This section applies when a REL is received before a final SIP 
response has been sent. Typically, this condition arises when a call 
has been rejected by the PSTN. 


Any gateway resources SHOULD be released immediately and an RLC MUST 
be sent to the ISUP network to indicate that the circuit is available 
for reuse. 


If the INVITE that originated this transaction contained a legitimate 
and comprehensible encapsulated ISUP message (i.e., an IAM using a 
variant supported by the gateway, preferably with a digital 
signature), then encapsulated ISUP SHOULD be sent in the response to 
the INVITE when possible (since this suggests an ISUP-SIP-ISUP 
bridging case) - therefore, the REL message just received SHOULD be 
included in the body of the SIP response. The gateway SHOULD NOT 
return a response with encapsulated ISUP if the originator of the 
INVITE did not enclose ISUP itself. 


Note that the receipt of certain maintenance messages in response to 
TAM such as Blocking Message (BLO) or Reset Message (RSC) (or their 
circuit group message equivalents) may also result in the teardown of 
calls in this phase of the state machine. Behavior for maintenance 
messages is given below in Section 11. 


7.2.4.1 ISDN Cause Code to Status Code Mapping 


The use of the REL message in the SS7 network is very general, 
whereas SIP has a number of specific tools that, collectively, play 
the same role as REL - namely BYE, CANCEL, and the various 
status/response codes. An REL can be sent to tear down a call that 
is already in progress (BYE), to cancel a previously sent call setup 
request that has not yet been completed (CANCEL), or to reject a call 
setup request (IAM) that has just been received (corresponding to a 
SIP status code). 


Note that it is not necessarily appropriate to map some ISDN cause 
codes to SIP messages because these cause codes are only meaningful 
to the ISUP interface of a gateway. A good example of this is cause 
code 44 "Request circuit or channel not available." 44 signifies that 
the CIC for which an IAM had been sent was believed by the receiving 
equipment to be in a state incompatible with a new call request - 
however, the appropriate behavior in this case is for the originating 
switch to re-send the IAM for a different CIC, not for the call to be 
torn down. Clearly, there is not (nor should there be) an SIP status 
code indicating that a new CIC should be selected - this matter is 
internal to the originating gateway. Hence receipt of cause code 44 
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should not result in any SIP status code being sent; effectively, the 
cause code is untranslatable. 


If a cause value other than those listed below is received, the 
default response '500 Server internal error” SHOULD be used. 


Finally, in addition to the ISDN Cause Code, the CAI parameter also 
contains a Cause 'location” that gives some sense of which entity in 
the network was responsible for terminating the call (the most 
important distinction being between the user and the network). In 
most cases, the cause location does not affect the mapping to a SIP 
status code; some exceptions are noted below. A diagnostic field may 
also be present for some ISDN causes; this diagnostic will contain 
additional data pertaining to the termination of the call. 


The following mapping values are RECOMMENDED: 


Normal event 


ISUP Cause value SIP response 

1 unallocated number 404 Not Found 

2 no route to network 404 Not found 

3 no route to destination 404 Not found 

16 normal call clearing == 00%) 

17 user busy 486 Busy here 

18 no user responding 408 Request Timeout 

19 no answer from the user 480 Temporarily unavailable 
20 subscriber absent 480 Temporarily unavailable 
21 call rejected 403 Forbidden (+) 

22 number changed (w/o diagnostic) 410 Gone 

22 number changed (w/ diagnostic) 301 Moved Permanently 

23 redirection to new destination 410 Gone 

26 non-selected user clearing 404 Not Found (=) 

27 destination out of order 502 Bad Gateway 

28 address incomplete 484 Address incomplete 

29 facility rejected 501 Not implemented 

31 normal unspecified 480 Temporarily unavailable 


(*) ISDN Cause 16 will usually result in a BYE or CANCEL 


(+) If the cause location is ’user’ than the 6xx code could be given 
rather than the 4xx code (i.e., 403 becomes 603) 


(=) ANSI procedure - in ANSI networks, 26 is overloaded to signify 
‘misrouted ported number’. Presumably, a number portability dip 
should have been performed by a prior network. Otherwise cause 26 is 
usually not used in ISUP procedures. 
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A REL with ISDN cause 22 (number changed) might contain information 
about a new number where the callee might be reachable in the 
diagnostic field. If the MGC is able to process this information it 
SHOULD be added to the SIP response (301) in a Contact header. 


Resource unavailable 


This kind of cause value indicates a temporary failure. A 'Retry- 
After’ header MAY be added to the response if appropriate. 


ISUP Cause value SIP response 

34 no circuit available 503 Service unavailable 
38 network out of order 503 Service unavailable 
41 temporary failure 503 Service unavailable 
42 switching equipment congestion 503 Service unavailable 
47 resource unavailable 503 Service unavailable 


Service or option not available 


This kind of cause value indicates that there is a problem with the 
request, rather than something that will resolve itself over time. 


ISUP Cause value SIP response 

55 incoming calls barred within CUG 403 Forbidden 

57 bearer capability not authorized 403 Forbidden 

58 bearer capability not presently 503 Service unavailable 
available 


Service or option not available 


ISUP Cause value SIP response 

65 bearer capability not implemented 488 Not Acceptable Here 
70 only restricted digital avail 488 Not Acceptable Here 
79 service or option not implemented 501 Not implemented 


Invalid message 


ISUP Cause value SIP response 
87 user not member of CUG 403 Forbidden 
88 incompatible destination 503 Service unavailable 
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Protocol error 


ISUP Cause value SIP response 

ndo eeeeearg or eT expiry na lia 

111 protocol error 500 Server internal error 
Interworking 

ISUP Cause value SIP response 

1 era unspecified ou Tania Inedec error 


7.2.5 Early ACM received 


An ACM message is sent in certain situations to indicate that the 
Call is in progress in order to satisfy ISUP timers, rather than to 
signify that the callee is being alerted. This occurs for example in 
mobile networks, where roaming can delay call setup significantly. 
The early ACM is sent before the user is alerted to reset T7 and 
start T9. An ACM is considered an 'early ACM” if the Called Party's 
Status Indicator is set to 00 (no indication). 


After sending an early ACM, the ISUP network can be expected to 
indicate the further progress of the call by sending CPGs. 


When an early ACM is received the gateway SHOULD send a 183 Session 
Progress response (see [1]) to the SIP network. In SIP bridging 
situations (where encapsulated ISUP was contained in the INVITE that 
initiated this call) the early ACM SHOULD also be included in the 
response body. 


Note that sending 183 before a gateway has confirmation that the 
address is complete (ACM) creates known problems in SIP bridging 
cases, and it SHOULD NOT therefore be sent. 


7.2.6 ACM received 


Most commonly, on receipt of an ACM a provisional response (in the 
18x class) SHOULD be sent to the SIP network. If the INVITE that 
initiated this session contained legitimate and comprehensible 
encapsulated ISUP, then the ACM received by the gateway SHOULD be 
encapsulated in the provisional response. 


If the ACM contains a Backward Call Indicators parameter with a value 
of ’subscriber free’, the gateway SHOULD send a '180 Ringing’ 
response. When a 180 is sent, it is assumed, in the absence of any 
early media extension, that any necessary ringback tones will be 
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generated locally by the SIP user agent to which the gateway is 
responding (which may in turn be a gateway). 


If the Backward Call Indicators (BCI) parameter of the ACM indicates 
that interworking has been encountered (generally designating that 
the ISUP network sending the ACM is interworking with a less 
sophisticated network which cannot report its status via out-of-band 
signaling), then there may be in-band announcements of call status 
such as an audible busy tone or Caller intercept message, and if 
possible a backwards media transmission SHOULD be initiated. 
Backwards media SHOULD also be transmitted if the Optional Backward 
Call Indicators parameter field for in-band media is set. For more 
information on early media (before 200 OK/ANM) see Section 5.5. 
After early media transmission has been initiated, the gateway SHOULD 
send a 183 Session Progress response code. 


Gateways MAY have some means of ascertaining the disposition of in- 
band audio media; for example, a way of determining by inspecting 
signaling in some ISUP variants, or by listening to the audio, that 
ringing, or a busy tone, is being played over the circuit. Such 
gateways MAY elect to discard the media and send the corresponding 
response code (such as 180 or 486) in its stead. However, the 
implementation of such a gateway would entail overcoming a number of 
known challenges that are outside the scope of this document. 


When they receive an ACM, switches in many ISUP networks start a 
timer known as "T9" which usually lasts between 90 seconds and 3 
minutes (see [13]). When early media is being played, this timer 
permits the caller to hear backwards audio media (in the form 
ringback, tones or announcements) from a remote switch in the ISUP 
network for that period of time without incurring any charge for the 
connection. The nearest possible local ISUP exchange to the callee 
generates the ringback tone or voice announcements. If longer 
announcements have to be played, the network has to send an ANM, 
which initiates bidirectional media of indefinite duration. In 
common ISUP network practice, billing commences when the ANM is 
received. Some networks do not support timer T9. 


7.2.7 CON or ANM Received 


When an ANM or CON message is received, the call has been answered 
and thus '200 OK’ response SHOULD be sent to the SIP network. This 
200 OK SHOULD contain an answer to the media offered in the INVITE. 
In SIP bridging situations (when the INVITE that initiated this call 
contained legitimate and comprehensible encapsulated ISUP), the ISUP 
message is included in the body of the 200 OK response. If it has 
not done so already, the gateway MUST establish a bidirectional media 
stream at this time. 
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When there is interworking with some legacy networks, it is possible 
for an ISUP switch to receive an ANM immediately after an early ACM 
(without CPG or any other backwards messaging), or without receiving 
any ACM at all (when an automaton answers the call). In this 
situation the SIP user will never have received a 18x provisional 
response, and consequently they will not hear any kind of ringtone 
before the callee answers. This may result in some clipping of the 
initial forward media from the caller (since forward media 
transmission cannot commence until SDP has been acquired from the 
destination). In ISDN (see [12]) this is solved by connecting the 
voice path backwards before sending the IAM. 


7.2.8 Timer T9 Expires 


The expiry of this timer (which is not used in all networks) 
signifies that an ANM has not arrived a significant period of time 
after alerting began (with the transmission of an ACM) for this call. 
Usually, this means that the callee’s terminal has been alerted for 
many rings but has not been answered. It may also occur in 
interworking cases when the network is playing a status announcement 
(such as one indicating that a number is not in service) that has 
cycled several times. Whatever the cause of the protracted 
incomplete call, when this timer expires the call MUST be released. 
All of the gateway resources related to the media path SHOULD be 
released. A ’480 Temporarily Unavailable’ response code SHOULD be 
sent to the SIP network, and an REL message with cause value 19 (no 
answer from the user) SHOULD be sent to the ISUP network. The PSTN 
can be expected to respond with an RLC and the SIP network to respond 
with an ACK indicating that the release sequence has been completed. 


7.2.9 CPG Received 


A CPG is a provisional message that can indicate progress, alerting 
or in-band information. If a CPG suggests that in-band information 
is available, the gateway SHOULD begin to transmit early media and 
cut through the unidirectional backwards media path. 
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In SIP bridging situations (when the INVITE that initiated this 
session contained legitimate and comprehensible encapsulated ISUP), 
the CPG SHOULD be sent in the body of a particular 18x response, 
determined from the CPG Event Code as follows: 


ISUP event code SIP response 

1 Alerting 180 Ringing 

2 Progress 183 Session progress 

3 In-band information 183 Session progress 

4 Call forward; line busy 181 Call is being forwarded 
5 Call forward; no reply 181 Call is being forwarded 
6 Call forward; unconditional 181 Call is being forwarded 
- (no event code present) 183 Session progress 


Note that if the CPG does not indicate "Alerting," the current state 
will not change. 


7.3 ACK received 


8. 


At this stage, the call is fully connected and the conversation can 
take place. No ISUP message should be sent by the gateway when an 
ACK is received. 


ISUP to SIP Mapping 


8.1 ISUP to SIP Call Flows 


The following call flows illustrate the order of messages in typical 
success and error cases when setting up a call initiated from the 
PSTN network. "100 Trying" acknowledgements to INVITE requests are 
not depicted, since their presence is optional. 


In these diagrams, all call signaling (SIP, ISUP) is going to and 
from the MGC; media handling (e.g., audio cut-through, trunk freeing) 
is being performed by the MG, under the control of the MGC. For the 
purpose of simplicity, these are shown as a single node, labeled 
"MGC/MG". 
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8.1.1 En-bloc call setup (non auto-answer) 


SIP MGC/MG PSTN 
| |<----------- IAM----------- |1 
| | Audio >| 

2|<-------- INVITE----------- | | 
|----------- 100----------- >| | 
3|----------- 18x----------- >| | 
========== Audi 0==========> 
| : 
| |------------ ACM---------- >|4 
5 | ----------- 18x----------- >| | 
| |------------ CPG---------- >|6 
7 |----------- 200- (1) ------- > | | 
| <========= Audi o========== >| 
ooo - ANM---------->| 8 
| < Audio > 
9 | <---------- ACK------------ | | 
1. When a PSTN user wishes to begin a session with a SIP user, the 


PSTN network generates an IAM message towards the gateway. 


2. Upon receipt of the IAM message, the gateway generates an INVITE 
message, and sends it to an appropriate SIP node. 


3. When an event signifying that the call has sufficient addressing 
information occurs, the SIP node will generate a provisional 
response of 180 or greater. 


4. Upon receipt of a provisional response of 180 or greater, the 
gateway will generate an ACM message. If the response is not 
180, the ACM will carry a "called party status" value of "no 
indication." 

5. The SIP node may use further provisional messages to indicate 


session progress. 


6. After an ACM has been sent, all provisional responses will 
translate into ISUP CPG messages as indicated in Section 8.2.3. 


7. When the SIP node answers the call, it will send a 200 OK 
message. 


8. Upon receipt of the 200 OK message, the gateway will send an ANM 
message towards the ISUP node. 


9. The gateway will send an ACK to the SIP node to acknowledge 
receipt of the INVITE final response. 


Camarillo, et. al. Standards Track [Page 31] 


RFC 3398 ISUP to SIP Mapping November 2002 


8.1.2 Auto-answer Call setup 


SIP MGC/MG PSTN 
| |<----------- IAM----------- |1 
| | Audio >| 
2|<-------- INVITE----------- | | 
3|----------- 200----------- >| | 
| <========= Audio========== >| 
------------ CON----------> |4 
< Audio > 
5|<---------- ACK------------ | | 
1. When a PSTN user wishes to begin a session with a SIP user, the 


PSTN network generates an IAM message towards the gateway. 


2. Upon receipt of the IAM message, the gateway generates an INVITE 
message and sends it to an appropriate SIP node based on called 
number analysis. 


3. Since the SIP node is set up to automatically answer the call, it 
will send a 200 OK message. 


4. Upon receipt of the 200 OK message, the gateway will send a CON 
message towards the ISUP node. 


5. The gateway will send an ACK to the SIP node to acknowledge 
receipt of the INVITE final response. 
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SIP MGC/MG PSTN 
| |<----------- IAM----------- |1 
| | Audio >| 

2 | <-------- INVITE----------- | | 
| *** Tl Expires *** | 
3 | <-------- INVITE----------- | 
*** TI Expires *** | 
<-------- INVITE----------- 


| *** T11 Expires *** 


| | ------------ ACM---------- > 
| *** Tl Expires *** | 
| 
| *** Tl Expires *** | 
<-------- INVITE----------- 
kx% TL Expires *** | 
Ko INVITE----------- | 
AX TL Expires *** | 
<-------- INVITE----------- | 


| 
| 
| 
| 
<-------- INVITE----------- | | 
| 
| 
| 
| 
| 


| 

| 

| *** T1 Expires *** | 

| ** MG Releases PSTN Trunk ** 
| 

| 


When a PSTN user wishes to begin a session with a SIP user, the 


PSTN network generates an IAM message towards the gateway. 


Upon receipt of the IAM message, the gateway generates an 
message, and sends it to an appropriate SIP node based on 
number analysis. The ISUP timer T11 and SIP timer T1 are 
this time. 


INVITE 
called 
set at 


The INVITE message will continue to be sent to the SIP node each 
time the timer T1 expires. The SIP standard specifies that 
INVITE transmission will be performed 7 times if no response is 


received. 
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4. When T11 expires, an ACM message will be sent to the ISUP node to 
prevent the call from being torn down by the remote node’s ISUP 
T7. This ACM contains a 'Called Party Status’ value of ‘no 
indication.’ 


5. Once the maximum number of INVITE requests has been sent, the 
gateway will send a REL (cause code 18) to the ISUP node to 


terminate the call. 


6. The gateway also sends a CANCEL message to the SIP node to 
terminate any initiation attempts. 


7. Upon receipt of the REL, the remote ISUP node will send an RIC to 
acknowledge. 


8.1.4 ISUP T9 Expires 


SIP MGC/MG PSTN 
| | <----------- IAM----------- |1 
| | Audio >| 

2|<-------- INVITE----------- | | 
*** TI Expires *** | | 
3 | <-------- INVITE----------- 
| *** Tl Expires *** | | 
|<-------- INVITE----------- | | 
| | *** T11 Expires *** | 
| |------------ ACM---------- >|4 
*** Tl Expires *** | | 
<-------- INVITE----------- 
*** TI Expires: *** | | 
<-------- INVITE----------- | | 
*** TI Expires *** | | 
<-------- INVITE----------- | 


| 
| 
| 

| *** T9 Expires *** 

** MG Releases PSTN Trunk ** 

| 
| 
| 


| <----------- REL----------- |5 
|------------ RLC---------- >|6 
7 | <-------- CANCEL----------- | | 
1. When a PSTN user wishes to begin a session with a SIP user, the 


PSTN network generates an IAM message towards the gateway. 


2. Upon receipt of the IAM message, the gateway generates an INVITE 
message, and sends it to an appropriate SIP node based on called 
number analysis. The ISUP timer T11 and SIP timer Tl are set at 
this time. 
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3. The INVITE message will continue to be sent to the SIP node each 
time the timer T1 expires. The SIP standard specifies that 
INVITE transmission will be performed 7 times if no response is 
received. Since SIP Tl starts at 1/2 second or more and doubles 
each time it is retransmitted, it will be at least a minute 
before SIP times out the INVITE request; since SIP Tl is allowed 
to be larger than 500 ms initially, it is possible that 7 x SIP 
T1 will be longer than ISUP T11 + ISUP T9. 


4. When T11 expires, an ACM message will be sent to the ISUP node to 
prevent the call from being torn down by the remote node’s ISUP 
T7. This ACM contains a 'Called Party Status’ value of ‘no 
indication.’ 


5. When ISUP T9 in the remote PSTN node expires, it will send a REL. 


6. Upon receipt of the REL, the gateway will send an RLC to 
acknowledge. 


7. The REL will trigger a CANCEL request, which gets sent to the SIP 
node. 


8.1.5 SIP Error Response 


SIP MGC/MG PSTN 
| |<----------- IAM----------- |1 
| | Audio >| 
2 | <-------- INVITE----------- 
3 RESTS RES 4xx+---------- > 
4 | <---------- ACK------------ | | 
| ** MG Releases PSTN Trunk ** 
| |------------ REL---------- >|5 
| |<----------- RLC----------- |6 
1. When a PSTN user wishes to begin a session with a SIP user, the 


PSTN network generates an IAM message towards the gateway. 


2. Upon receipt of the IAM message, the gateway generates an INVITE 
message, and sends it to an appropriate SIP node based on called 
number analysis. 


3. The SIP node indicates an error condition by replying with a 
response with a code of 400 or greater. 


4. The gateway sends an ACK message to acknowledge receipt of the 
INVITE final response. 
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An ISUP REL message is generated from the SIP code, as specified 
in Section 8.2.6.1. 


The remote ISUP node confirms receipt of the REL message with an 
RLC message. 


8.1.6 SIP Redirection 


SIP node 1 MGC /MG PSTN 
| | <----------- IAM----------- |1 
| | Audio >| 

2 | <-------- INVITE----------- | | 
3|----------- IXXP==== === >| 
| |------------ CPG---------- >|4 
5 | <---------- ACK------------ | | 
SIP node 2 | | 
6|<-------- INVITE----------- | | 
7|----------- 18x----------- >| 
| <========= Audio=========== | | 
Lolo ACM---------->|8 
9 | ----------- 200- (I) ------- > 
| <========= Audi o========== >| 
| |------------ ANM---------- >|10 
| |< Audio >| 
11|<---------- ACK------------ | | 


When a PSTN user wishes to begin a session with a SIP user, the 
PSTN network generates an IAM message towards the gateway. 


Upon receipt of the IAM message, the gateway generates an INVITE 
message, and sends it to an appropriate SIP node based on called 
number analysis. 


The SIP node indicates that the resource which the user is 
attempting to contact is at a different location by sending a 3xx 
message. In this instance we assume the Contact URL specifies a 
valid URL reachable by a VoIP SIP call. 


The gateway sends a CPG with event indication that the call is 
being forwarded upon receipt of the 3xx message. Note that this 
translation should be able to be disabled by configuration, as 
some ISUP nodes do not support receipt of CPG messages before ACM 
messages. 


The gateway acknowledges receipt of the INVITE final response by 
sending an ACK message to the SIP node. 
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TO; 


EI 


The gateway re-sends the INVITE message to the address indicated 
in the Contact: field of the 3xx message. 


When an event signifying that the call has sufficient addressing 
information occurs, the SIP node will generate a provisional 
response of 180 or greater. 


Upon receipt of a provisional response of 180 or greater, the 
gateway will generate an ACM message with an event code as 
indicated in Section 8.2.3. 


When the SIP node answers the call, it will send a 200 OK 
message. 


Upon receipt of the 200 OK message, the gateway will send an ANM 
message towards the ISUP node. 


The gateway will send an ACK to the SIP node to acknowledge 
receipt of the INVITE final response. 


8.1.7 Call Canceled by ISUP 


SIP MGC/MG PSTN 
| |<----------- IAM----------- |1 
| | Audio >| 

2 | <-------- INVITE----------- | | 
3|----------- 18x----------- >| | 
SS Audi 0==========> 
| ------------ ACM---------- >|4 
| ** MG Releases PSTN Trunk ** 
| | <----------- REL----------- |5 
| |------------ RLC---------- >|6 
7 | <--------- CANCEL---------- | | 
** MG Releases IP Resources ** 
8| ----------- 200----------- >| 
9 | ----------- 487----------- >| | 
10 |<---------- ACK------------ | | 


When a PSTN user wishes to begin a session with a SIP user, the 
PSTN network generates an IAM message towards the gateway. 


Upon receipt of the IAM message, the gateway generates an INVITE 
message, and sends it to an appropriate SIP node based on called 
number analysis. 


When an event signifying that the call has sufficient addressing 
information occurs, the SIP node will generate a provisional 
response of 180 or greater. 
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10. 


Upon receipt of a provisional response of 180 or greater, the 
gateway will generate an ACM message with an event code as 
indicated in Section 8.2.3. 


If the calling party hangs up before the SIP node answers the 
call, a REL message will be generated. 


The gateway frees the PSTN circuit and indicates that it is 
available for reuse by sending an RLC. 


Upon receipt of a REL message before an INVITE final response, 
the gateway will send a CANCEL towards the SIP node. 


Upon receipt of the CANCEL, the SIP node will send a 200 
response. 


The remote SIP node will send a "487 Call Cancelled" to complete 
the INVITE transaction. 


The gateway will send an ACK to the SIP node to acknowledge 
receipt of the INVITE final response. 
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8.2 State Machine 


November 2002 


Note that REL may arrive in any state. Whenever this occurs, the 
actions in section Section 8.2.7. are taken. Not all of these 


transitions are shown in this diagram. 


+--------- + 
+----------------------- >| Idle  |<--------------------- + 

+—----+----+ 

| 
| | IAM/7.2.1 | 
| v | 
| REL/7.2.7 HO + 400+/7.2.6 | 
ER T E + Trying | Ses ee > | 
| +-+-------- +------ +------—- + 
| T11/ 18x/ 200/ | 
| Aa a as | 
| v | | | 
| REL/7.2.7 +-------------- + | | 400+/7.2.6 
| <---------- | Progressing |-|------ | -------------------- > | 
| +--+----+------ + 
| 
| 200/ | | 18x/ | | | 
| 7.2.4 | [5237 | | 
| | ov v | | 
| REL/7.2.7 | +--------------- + | 400+/7.2.6 
KS SS Sea |S | Alerting | - | -------------------- > 
+-------- +------ + 
| | | | | 
| | | 200/ | | 
| | E | 
| v v v | 
| BYE/9.1 +----------------------------- + REL/9.2 | 
122 RAR AA + Connected a ar >+ 
4+—----------------------------- + 
8.2.1 Initial Address Message received 
Upon receipt of an IAM, the gateway SHOULD reserve appropriate 
internal resources (Digital Signal Processors - DSPs - and the like) 


necessary for handling the IP side of the call. 


It MAY make any 


necessary preparations to connect audio in the backwards direction 


(towards the caller). 
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8.2.1.1 IAM to INVITE procedures 


When an IAM arrives at a PSTN-SIP gateway, a SIP INVITE message MUST 
be created for transmission to the SIP network. This section details 
the process by which a gateway populates the fields of the INVITE 
based on parameters found within the IAM. 


The context of the call setup request read by the gateway in the IAM 
will be mapped primarily to two URIs in the INVITE, one representing 
the originator of the session and the other its destination. The 
former will always appear in the From header (after it has been 
converted from ISUP format by the procedure described in Section 12), 
and the latter is almost always used for both the To header and the 
Request-URI. 


Once the address of the called party number has been read from the 
IAM, it SHOULD be translated into a destination tel URL that will 
serve as the Request-URI of the INVITE. Alternatively, a gateway MAY 
first attempt a Telephone Number Mapping (ENUM) [8] query to resolve 
the called party number to a URI. Some additional ISUP fields MAY be 
added to the tel URL after translation has been completed, namely: 


o If the gateway supports carrier-based routing (which is optional 
in this specification), it SHOULD ascertain if either the CIP (in 
ANSI networks) or TNS parameter is present in the IAM. If a value 
is present, the CIC SHOULD be extracted from the given parameter 
and analyzed by the gateway. A 'cic=" field with the value of the 
CIC SHOULD be appended to the destination tel URL, if doing so is 
in keeping with local policy (i.e., provided that the CIC does not 
indicate the network which owns the gateway or some similar 
condition). Note that if it is created, the 'cic=" parameter MUST 
be prefixed with the country code used or implied in the called 
party number, so that CIC '5062” becomes, in the United States, 
/+1-5062'. For further information on the 'cic=" tel URL field 
see [21]. 


o If the gateway supports number portability-based routing (which is 
optional in this specification), then the gateway will need to 
look at a few other fields. To correctly map the FCI 'number 
translated” bit indicating that an LNP dip had been performed in 
the PSTN, an 'npdi=yes' field SHOULD be appended to the tel URL. 
If a GAP is present in the IAM, then the contents of the CPN (the 
Location Routing Number - LRN) SHOULD be translated from ISUP 
format (as described in Section 12) and copied into an 'rn=" field 
which must be appended to the tel URL, whereas the GAP itself 
should be translated to ISUP format and used to populate the 
primary telephone number field of the tel URL. Note that in some 
national numbering plans, both the LRN and the dialed number may 
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be stored in the CPN parameter, in which case they must be 
separated out into different fields to be stored in the tel URL. 
Note that LRNs are necessarily national in scope, and consequently 
they MUST NOT be preceded by a ’+’ in the 'rn=” field. For 
further information on these tel URL fields see [21]. 


In most cases, the resulting destination tel URL SHOULD be used in 
both the To field and Request-URI sent by the gateway. However, if 
the OCN parameter is present in the IAM, the To field SHOULD be 
constructed from the translation (from ISUP format following Section 
12 of the OCN parameter, and hence the Request-URI and To field MAY 
be different. 


The construction of the From header field is dependent on the 
presence of a CIN parameter. If the CIN is not present, then the 
gateway SHOULD create a dummy From header field containing a SIP URI 
without a user portion which communicates only the hostname of the 
gateway (e.g., 'sip:gw.sipcarrier.com). If the CIN is available, 
then it SHOULD be translated (in accordance with the procedure 
described above) into a tel URL which should populate the From header 
field. In either case, local policy or requests for presentation 
restriction (see Section 12.1) MAY result in a different value for 
the From header field. 


8.2.2 100 received 


A 100 response SHOULD NOT trigger any PSTN interworking messages; it 
only serves the purpose of suppressing INVITE retransmissions. 


8.2.3 18x received 


Upon receipt of a 18x provisional response, if no ACM has been sent 
and no legitimate and comprehensible ISUP is present in the 18x 
message body, then the ISUP message SHOULD be generated according to 
the following table. Note that if an early ACM is sent, the call 
MUST enter state "Progressing" instead of state "Alerting." 


Response received Message sent by the MGC 
180 Ringing ACM (BCI = subscriber free) 
181 Call is being forwarded Early ACM and CPG, event=6 
182 Queued ACM (BCI = no indication) 
183 Session progress message ACM (BCI = no indication) 
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If an ACM has already been sent and no ISUP is present in the 18x 
message body, an ISUP message SHOULD be generated according to the 
following table. 


Response received Message sent by the MGC 
180 Ringing CPG, event = 1 (Alerting) 
181 Call is being forwarded CPG, event = 6 (Forwarding) 
182 Queued CPG, event = 2 (Progress) 
183 Session progress message CPG, event = 2 (Progress) 


Upon receipt of a 180 response, the gateway SHOULD generate the 
ringback tone to be heard by the caller on the PSTN side (unless the 
gateway knows that ringback will be provided by the network on the 
PSTN side). 


Note however that a gateway might receive media at any time after it 
has transmitted an SDP offer that it has sent in an INVITE, even 
before a 18x provisional response is received. Therefore the gateway 
MUST be prepared to play this media to the caller on the PSTN side 
(if necessary, ceasing any ringback tone that it may have begun to 


generate and then playing media). Note that the gateway may also 
receive SDP offers in responses for an early media session using some 
SIP extension, see Section 5.5. If a gateway receives a 183 response 


while it is playing backwards media, then when it generates a mapping 
for this response, if no encapsulated ISUP is present, the gateway 
SHOULD indicate that in-band information is available (for example, 
with the Event Information parameter of the CPG message or the 
Optional Backward Call Indicators parameter of the ACM). 


When an ACM is sent, the mandatory Backward Call Indicators parameter 
must be set, as well as any optional parameters as gateway policy 
dictates. If legitimate and comprehensible ISUP is present in the 
18x response, the gateway SHOULD re-use the appropriate parameters of 
the ISUP message contained in the response body, including the value 
of the Backward Call Indicator parameter, as it formulates a message 
that it will send across its PSTN interface. In the absence of a 
usable encapsulated ACM, the BCI parameter SHOULD be set as follows: 
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Message type: ACM 


Backward Call Indicators 


Charge indicator: 10 charge 

Called party’s status indicator: 01 subscriber free or 
00 no indication 

Called party’s category indicator: 01 ordinary subscriber 

End-to-end method indicator: 00 no end-to-end method 

Interworking indicator: 0 no interworking 

End-to-end information indicator: O no end-to-end info 


ISDN user part indicator: 1 ISUP used all the way 
Holding indicator: 0 no holding 

ISDN access indicator: O No ISDN access 

Echo control device indicator: It depends on the call 
SCCP method indicator: 00 no indication 


Note that when the ISUP Backward Call Indicator parameter 
Interworking indicator field is set to 'interworking encountered’, 
this indicates that ISDN is interworking with a network which is not 
capable of providing as many services as ISDN does. ISUP therefore 
may not employ certain features it otherwise normally uses. Gateway 
vendors MAY however provide a configurable option, usable at the 
discretion of service providers when they require additional ISUP 
services, that in the absence of encapsulated ISUP will signal in the 
BCI that interworking has been encountered, and that ISUP is not used 
all the way, for those operators that as a matter of policy would 
rather operate in this mode. For more information on the effects of 
interworking see Section 7.2.1.1. 


8.2.4 2xx received 


Response received Message sent by the MGC 


200 OK ANM, ACK 


After receiving a 200 OK response the gateway MUST establish a 
directional media path in the gateway and send an ANM to the PSTN as 
well as an ACK to the SIP network. 


If the 200 OK response arrives before the gateway has sent an ACM, a 
CON is sent instead of the ANM, in those ISUP variants that support 
the CON message. 


When a legitimate and comprehensible ANM is encapsulated in the 200 


OK response, the gateway SHOULD re-use any relevant ISUP parameters 
in the ANM it sends to the PSTN. 
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Note that gateways may sometimes receive 200 OK responses for 
requests other than INVITE (for example, those used in managing 
provisional responses, or the INFO method). The procedures described 
in this section apply only to 200 OK responses received as a result 
of sending an INVITE. The gateway SHOULD NOT send any PSTN messages 
if it receives a 200 OK in response to non-INVITE requests it has 
sent. 


8.2.5 3xx Received 


When any 3xx response (a redirection) is received, the gateway SHOULD 
try to reach the destination by sending one or more new call setup 
requests using URIs found in any Contact header field(s) present in 
the response, as is mandated in the base SIP specification. Such 3xx 
responses are typically sent by a redirect server, and can be thought 
of as similar to a location register in mobile PSTN networks. 


If a particular URI presented in the Contact header of a 3xx is best 
reachable (according to the gateway’s routing policies) via the PSTN, 
the gateway SHOULD send a new IAM and from that moment on act as a 
normal PSTN switch (no SIP involved) - usually this will be the case 
when the URI in the Contact header is a tel URL, one that the gateway 
cannot reach locally and one for which there is no ENUM mapping. 


Alternatively, the gateway MAY send a REL message to the PSTN with a 
redirection indicator (23) and a diagnostic field corresponding to 
the telephone number in the URI. If, however, the new location is 
best reachable using SIP (if the URI in the Contact header contains 
no telephone number at all), the MGC SHOULD send a new INVITE with a 
Request-URI possibly a new IAM generated by the MGC in the message 
body. 


While it is exploring a long list of Contact header fields with SIP 
requests, a gateway MAY send a CPG message with an event code of 6 
(Forwarding) to the PSTN in order to indicate that the call is 
proceeding (where permitted by the ISUP variant in question). 


All redirection situations have to be treated very carefully because 
they involved special charging situations. In PSTN the caller 
typically pays for the first leg (to the gateway) and the callee pays 
the second (from the forwarding switch to the destination). 


8.2.6 4xx-6xx Received 


When a response code of 400 or greater is received by the gateway, 
then the INVITE previously sent by the gateway has been rejected. 
Under most circumstances the gateway SHOULD release the resources in 
the gateway, send a REL to the PSTN with a cause value and send an 


Camarillo, et. al. Standards Track [Page 44] 


RFC 3398 ISUP to SIP Mapping November 2002 


ACK to the SIP network. Some specific circumstances are identified 
below in which a gateway MAY attempt to rectify a SIP-specific 
problem communicated by a status code without releasing the call by 
retrying the request. When a REL is sent to the PSTN, the gateway 
expects the arrival of an RLC indicating that the release sequence is 
complete. 


8.2.6.1 SIP Status Code to ISDN Cause Code Mapping 


When a REL message is generated due to a SIP rejection response that 
contains an encapsulated REL message, the Cause Indicator (CAI) 
parameter in the generated REL SHOULD be set to the value of the CAI 


parameter received in the encapsulated REL. If no encapsulated ISUP 
is present, the mapping below between status code and cause codes are 
RECOMMENDED. 


Any SIP status codes not listed below (associated with SIP 
extensions, versions of SIP subsequent to the issue of this document, 
or simply omitted) should be mapping to cause code 31 "Normal, 
unspecified". These mappings cover only responses; note that the BYE 
and CANCEL requests, which are also used to tear down a dialog, 
SHOULD be mapped to 16 "Normal clearing" under most circumstances 
(although see Section 5.8). 


By default, the cause location associated with the CAI parameter 
should be encoded such that 6xx codes are given the location 'user', 
whereas 4xx and 5xx codes are given a 'network” location. Exceptions 
are marked below. 
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Just as there are certain ISDN cause codes that are ISUP-specific and 


have no corollary SIP action, 


so there are SIP status codes that 


should not simply be translated to ISUP - some SIP-specific action 


should be attempted first. 


Response received 


Camarillo, 


Bad Request 
Unauthorized 
Payment required 
Forbidden 

Not found 

Method not allowed 


Not acceptable 


Proxy authentication required 
Request timeout 
Gone 


Request Entity too long 
Request-URI too long 
Unsupported media type 


Unsupported URI Scheme 
Bad extension 

Extension Required 
Interval Too Brief 
Temporarily unavailable 
Call/Transaction Does not Exist 
Loop Detected 

Too many hops 

Address incomplete 
Ambiguous 

Busy here 

Request Terminated 

Not Acceptable here 
Server internal error 
Not implemented 

Bad gateway 

Service unavailable 
Server time-out 

Version Not Supported 
Message Too Large 

Busy everywhere 

Decline 

Does not exist anywhere 
Not acceptable 


et. al. 


See the note on the 


Standards Track 


(+) tag below. 


Cause value in the REL 
41 Temporary Failure 
Call rejected (*) 
Call rejected 

Call rejected 

1 Unallocated number 
63 Service or option 
unavailable 
Service/option not 
implemented (+) 

Call rejected (*) 
Recovery on timer expiry 
Number changed 

(w/o diagnostic) 
Interworking (+) 
Interworking (+) 
Service/option not 
implemented (+) 
Interworking (+) 
Interworking (+) 
Interworking (+) 
Interworking (+) 

18 No user responding 

41 Temporary Failure 
Exchange - routing error 
Exchange - routing error 
Invalid Number Format (+) 
1 Unallocated number 

17 User busy 

(no mapping) 

by Warning header 

41 Temporary failure 

Not implemented, unspecified 
Network out of order 

41 Temporary failure 


102 Recovery on timer expiry 
127 Interworking (+) 
127 Interworking (+) 


17 User busy 

Call rejected 

1 Unallocated number 
by Warning header 
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(*) In some cases, it may be possible for a SIP gateway to provide 
credentials to the SIP UAS that is rejecting an INVITE due to 
authorization failure. If the gateway can authenticate itself, then 
obviously it SHOULD do so and proceed with the call; only if the 
gateway cannot authenticate itself should cause code 21 be sent. 


(+) If at all possible, a SIP gateway SHOULD respond to these 
protocol errors by remedying unacceptable behavior and attempting to 
re-originate the session. Only if this proves impossible should the 
SIP gateway fail the ISUP half of the call. 


When the Warning header is present in a SIP 606 or 488 message, there 
may be specific ISDN cause code mappings appropriate to the Warning 
code. This document recommends that '31 Normal, unspecified’ SHOULD 
by default be used for most currently assigned Warning codes. If the 
Warning code speaks to an unavailable bearer capability, cause code 
'65 Bearer Capability Not Implemented’ is a RECOMMENDED mapping. 


8.2.7 REL Received 


This circumstance generally arises when the user on the PSTN side 
hangs up before the call has been answered; the gateway therefore 
aborts the establishment of the session. A CANCEL request MUST be 
issued (a BYE is not used, since no final response has arrived from 
the SIP side). A 200 OK for the CANCEL can be expected by the 
gateway, and finally a 487 for the INVITE arrives (which the gateway 
ACKs in turn). 


The gateway SHOULD store state information related to this dialog for 
a certain period of time, since a 200 final response for the INVITE 
originally sent might arrive (even after the reception of the 200 OK 
for the CANCEL). In this situation, the gateway MUST send an ACK 
followed by an appropriate BYE request. 


In SIP bridging situations, the REL message cannot be encapsulated in 
a CANCEL message (since CANCEL cannot have a message body). Usually, 
the REL message will contain a CAI value of 16 "Normal clearing". If 
the value is other than a 16, the gateway MAY wish to use some other 
means of communicating the cause value (see Section 5.8). 


8.2.8 ISUP T11 Expires 


In order to prevent the remote ISUP node’s timer T7 from expiring, 
the gateway MAY keep its own supervisory timer; ISUP defines this 


timer as T11. T11’s duration is carefully chosen so that it will 
always be shorter than the T7 of any node to which the gateway is 
communicating. 
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9. 


To clarify timer T11’s relevance with respect to SIP interworking, 
Q.764 [12] explains its use as: "If in normal operation, a delay in 
the receipt of an address complete signal from the succeeding network 
is expected, the last common channel signaling exchange will 
originate and send an address complete message 15 to 20 seconds 
[timer (T11)] after receiving the latest address message." Since SIP 
nodes have no obligation to respond to an INVITE request within 20 
seconds, SIP interworking inarguably qualifies as such a situation. 


If the gateway supports this optional mechanism, then if its T11 
expires, it SHOULD send an early ACM (i.e., called party status set 
to "no indication") to prevent the expiration of the remote node’s T7 
(where permitted by the ISUP variant). See Section 8.2.3 for the 
value of the ACM parameters. 


If a "180 Ringing" message arrives subsequently, it SHOULD be sent in 
a CPG, as shown in Section 8.2.3. 


See Section 8.1.3 for an example callflow that includes the 
expiration of T11. 


Suspend/Resume and Hold 


9.1 Suspend (SUS) and Resume (RES) Messages 


In ISDN networks, a user can generate a SUS (timer T2, user 
initiated) in order to unplug the terminal from the socket and plug 
it in another one. A RES is sent once the terminal has been 
reconnected and the T2 timer has not expired. SUS is also frequently 
used to signaling an on-hook state for a remote terminal before 
timers leading to the transmission of a REL message are sent (this is 
the more common case by far). While a call is suspended, no audio 
media is passed end-to-end. 


When a SUS is sent for a Call that has a SIP leg, a gateway MAY 
suspend IP media transmission until a RES is received. Putting the 
media on hold insures that bandwidth is conserved when no audio 
traffic needs to be transmitted. 


If media suspension is appropriate, then when a SUS arrives from the 
PSTN, the MGC MAY send an INVITE to request that the far-end’s 
transmission of the media stream be placed on hold. The subsequent 
reception of a RES from the PSTN SHOULD then trigger a re-INVITE that 
requests the resumption of the media stream. Note that the MGC may 
or may not elect to stop transmitting any media itself when it 
requests the cessation of far-end transmission. 


Camarillo, et. al. Standards Track [Page 48] 


RFC 3398 ISUP to SIP Mapping November 2002 


If media suspension is not required by the MGC receiving the SUS from 
the PSTN, the SIP INFO [6] method MAY be used to transmit an 
encapsulated SUS rather than a re-INVITE. Note that the recipient of 
such an INFO request may be a simple SIP phone that does not 
understand ISUP (and would therefore take no action on receipt of 
this message); if a prospective destination for an INFO-encapsulated 
SUS has not used encapsulated ISUP in any messages it has previously 
sent, the gateway SHOULD NOT relay the INFO method, but rather should 
handle the SUS and the corresponding RES without signaling their 
arrival to the SIP network. 


In any case, subsequent RES messages MUST be transmitted in the same 
method that was used for the corresponding SUS (i.e., if an INFO is 
used for a SUS, INFO should also be used for the subsequent RES). 


Regardless of whether the INFO or re-INVITE mechanism is used to 
carry a SUS message, neither has any implication that the originating 
side will cease sending IP media. The recipient of an encapsulated 
SUS message MAY therefore elect to send a re-INVITE themselves to 
suspend media transmission from the MGC side if desired. 


The following example uses the INVITE mechanism. Note that this flow 
is informative, not proscriptive; compliant gateways are free to 
implement functionally equivalent flows, as described in the 
preceding paragraphs. 


SIP MGC/MG PSTN 
<----------- SUS----------- 1 
2 |<-------- INVITE----------- | 
3 | ----------- 200----------- >| | 
4 |<---------- ACK------------ | | 
| |<----------- RES----------- |5 
6 | <-------- INVITE----------- | | 
7 | ----------- 200----------- > 
8 | <---------- ACK------------ | 


The handling of a network-initiated SUS immediately prior to call 
teardown is handled in Section 10.2.2. 


Camarillo, et. al. Standards Track [Page 49] 


RFC 3398 ISUP to SIP Mapping November 2002 


9.2 Hold (re-INVITE) 


After a call has been connected, a re-INVITE could be sent toa 
gateway from the SIP side in order to place the call on hold. This 
re-INVITE will have an SDP offer indicating that the originator of 
the re-INVITE no longer wishes to receive media. 


SIP MGC/MG PSTN 
1|--------- INVITE---------- > 
SeH Her CPG---------->|2 
3|<---------- 200------------ | | 
4|----------- ACK----------- > | 


When such a re-INVITE is received, the gateway SHOULD send a CPG in 
order to express that the call has been placed on hold. The CPG 
SHOULD contain a Generic Notification Indicator (or, in ANSI 
networks, a Notification Indicator) with a value of ’remote hold’. 


If, subsequent to the sending of the re-INVITE, the SIP side wishes 
to take the remote end off hold and begin receiving media again, it 
SHOULD repeat the flow above with an INVITE that contains an SDP 
offer with an appropriate media destination. The Generic 
Notification Indicator would in this instance have a value of ’remote 
retrieval’ (or in some variants 'remote hold released’). 


Finally, note that a CPG with hold indicators may be received by a 
gateway from the PSTN. In the interests of conserving bandwidth, the 
gateway SHOULD stop sending media until the call is resumed and 
SHOULD send a re-INVITE to the SIP leg of the call requesting that 
the remote side stop sending media. 


10. Normal Release of the Connection 


From the perspective of a gateway, either the SIP side or the ISUP 
side can release a call, regardless of which side initiated the call. 
Note that cancellation of a call setup request (either from the ISUP 
or SIP side) is discussed elsewhere in this document (in Section 
8.2.7 and Section 7.2.3, respectively). 


Gateways SHOULD implement functional equivalence with the flows in 
this section. 


10.1 SIP initiated release 
For a normal termination of the dialog (receipt of a BYE request), 
the gateway MUST immediately send a 200 response. The gateway then 


MUST release any media resources in the gateway (DSPs, TCIC locks, 
and so on) and send an REL with a cause code of 16 (normal call 
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clearing) to the PSTN. Release of resources is confirmed by the PSTN 
side with an RLC message. 


In SIP bridging situations, the cause code of any REL encapsulated in 
the BYE request SHOULD be re-used in any REL that the gateway sends 
to the PSTN. 


SIP MGC/MG PSTN 
1 | ----------- BYE----------- > | 
** MG Releases IP Resources ** 
2 | <---------- 200------------ | | 
| ** MG Releases PSTN Trunk ** 
| |------------ REL---------- >|3 
| |<----------- RLC----------- | 4 


-2 ISUP initiated release 


If the release of the connection was caused by the reception of a 
REL, the REL SHOULD be encapsulated in the BYE sent by the gateway. 
Whether the caller or callee hangs up first, the gateway SHOULD 
release any internal resources used in support of the call and then 
MUST confirm that the circuit is ready for re-use by sending an RLC. 


-2.1 Caller hangs up 


When the caller hangs up, the SIP dialog MUST be terminated by 
sending a BYE request (which is confirmed with a 200). 


SIP MGC/MG PSTN 
| | <----------- REL----------- |1 
| ** MG Releases PSTN Trunk ** 
| |------------ RLC---------- >|2 

3 | <---------- BYE------------ | 
** MG Releases IP Resources ** 
4|----------- 200----------- > 
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Tis 


11. 


2.2 Callee hangs up (SUS) 


In some PSTN scenarios, if the callee hangs up in the middle of a 
call, the local exchange sends a SUS instead of a REL and starts a 


timer (T6, SUS is network initiated). When the timer expires, the 
REL is sent. This necessitates a slightly different SIP flow; see 
Section 9 for more information on handling suspension. It is 


RECOMMENDED that gateways implement functional equivalence with the 
following flow for this case: 


SIP MGC/MG PSTN 
| |<----------- SUS----------- |1 
2|<-------- INVITE----------- | | 
3|----------- 200----------- >| | 
4 |<---------- ACK------------ | 
*xR. TO EXplires *** 
<----------- REL----------- 5 
| ** MG Releases PSTN Trunk ** 
| |------------ RLC---------- >|6 
7 | <---------- BYE------------ | | 
| ** MG Releases IP Resources ** 
8 | ----------- 200----------- > | | 
ISUP Maintenance Messages 
ISUP contains a set of messages used for maintenance purposes. They 
can be received during any ongoing call. There are basically two 


kinds of maintenance messages (apart from the continuity check): 
messages for blocking circuits and messages for resetting circuits. 


1 Reset messages 


Upon reception of an RSC message for a circuit currently being used 
by the gateway for a call, the call MUST be released immediately 
(this typically results from a serious maintenance condition). RSC 
MUST be answered with an RLC after resetting the circuit in the 
gateway. Group reset (GRS) messages which target a range of circuits 
are answered with a Circuit Group Reset ACK Message (GRA) after 
resetting all the circuits affected by the message. 


The gateways SHOULD behave as if a REL had been received in order to 
release the dialog on the SIP side. A BYE or a CANCEL are sent 
depending of the status of the call. See the procedures in Section 
10. 
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.2 Blocking messages 


There are two kinds of blocking messages: maintenance messages or 
hardware-failure messages. Maintenance blocking messages indicate 
that the circuit is to be blocked for any subsequent calls, but these 
messages do not affect any ongoing call. This allows circuits to be 
gradually quiesced and taken out of service for maintenance. 


Hardware-oriented blocking messages have to be treated as reset 
messages. They generally are sent only when a hardware failure has 
occurred. Media transmission for all calls in progress on these 
circuits would be affected by this hardware condition, and therefore 
all calls must be released immediately. 


BLO is always maintenance oriented and it is answered by the gateway 
with a Blocking ACK Message (BLA) when the circuit is blocked - this 
requires no corresponding SIP actions. Circuit Group Blocking (CGB) 
messages have a "type indicator" inside the Circuit Group Supervision 
Message Type Indicator. It indicates if the CGB is maintenance or 
hardware failure oriented. If the CGB results from a hardware 
failure, then each call in progress in the affected range of circuits 
MUST be terminated immediately as if a REL had been received, 
following the procedures in Section 10. CGBs MUST be answered with 
CGBAs. 


3 Continuity Checks 


A continuity check is a test performed on a circuit that involves the 
reflection of a tone generated at the originating switch by a 
loopback at the destination switch. Two variants of the continuity 
check appear in ISUP: the implicit continuity check request within an 
TAM (in which case the continuity check takes place as a precondition 
before call setup begins), and the explicit continuity check signaled 
by a Continuity Check Request (CCR) message. PSTN gateways in 
regions that support continuity checking generally SHOULD have some 
way of accommodating these tests (if they hope to be fielded by 
providers that interconnect with any major carrier). 


When a CCR is received by a PSTN-SIP gateway, the gateway SHOULD NOT 
send any corresponding SIP messages; the scope of the continuity 
check applies only to the PSTN trunks, not to any IP media paths 
beyond the gateway. CCR messages also do not designate any called 
party number, or any other way to determine what SIP user agent 
server should be reached. 


When an IAM with the Continuity Check Indicator flag set within the 
NCI parameter is received, the gateway MUST process the continuity 
check before sending an INVITE message (and proceeding normally with 
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call setup); if the continuity check fails (a COT with Continuity 
Indicator of 'failed” is received), then an INVITE MUST NOT be sent. 


Construction of Telephony URIs 


SIP proxy servers MAY route SIP messages on any signaling criteria 
desired by network administrators, but generally the Request-URI is 
the foremost routing criterion. The To and From headers are also 
frequently of interest in making routing decisions. SIP-ISUP mapping 
assumes that proxy servers are interested in at least these three 
fields of SIP messages, all of which contain URIs. 


SIP-ISUP mapping frequently requires the representation of telephone 
numbers in these URIs. In some instances these numbers will be 
presented first in ISUP messages, and SS7-SIP gateways will need to 
translate the ISUP formats of these numbers into SIP URIs. In other 
cases the reverse transformation will be required. 


The most common format used in SIP for the representation of 
telephone numbers is the tel URL [7]. When converting between 
formats, the tel URL MAY constitute the entirety of a URI field ina 
SIP message, or it MAY appear as the user portion of a SIP URI. For 
example, a To field might appear as: 


To: tel:+17208881000 
Or 
To: sip:+17208881000@level3.com 


Whether or not a particular gateway or endpoint should formulate URIs 
in the tel or SIP format is a matter of local administrative policy - 
if the presence of a host portion would aid the surrounding network 
in routing calls, the SIP format should be used. A gateway MUST 
accept either tel or SIP URIs from its peers. 


The ’+’ sign preceding the number in tel URLs indicates that the 
digits which follow constitute a fully-qualified E.164 [16] number; 
essentially, this means that a country code is provided before any 
national-specific area codes, exchange/city codes, or address codes. 
The absence of a ’+’ sign MAY signify that the number is merely 
nationally significant, or perhaps that a private dialing plan is in 
use. When the ’+’ sign is not present, but a telephone number is 
represented by the user portion of the URI, the SIP URI SHOULD 
contain the optional ’;user=phone’ parameter; e.g., 


To: sip:83000@sip.example.net;user=phone 
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However, it is strongly RECOMMENDED that only internationally 
significant E.164 numbers be passed between SIP-T gateways, 
especially when such gateways are in different regions or different 
administrative domains. In many if not most SIP-T networks, gateways 
are not responsible for end-to-end routing of SIP calls; practically 
speaking, gateways have no way of knowing if the call will terminate 
in a local or remote administrative domain and/or region, and hence 
gateways SHOULD always assume that calls require an international 
numbering plan. There is no guarantee that recipients of SIP 
signaling will be capable of understanding national dialing plans 
used by the originators of calls - if the originating gateway does 
not internationalize the signaling, the context in which the digits 
were dialed cannot be extrapolated by far-end network elements. 


In ISUP signaling, a telephone number appears in a common format that 
is used in several parameters, including the CPN and CIN; when it 
represents a calling party number it sports some additional 
information (detailed below). For the purposes of this document, we 
will refer to this format as ’ISUP format’ - if the additional 
calling party information is present, the format shall be referred to 
as ’ISUP- calling format’. The format consists of a byte called the 
Nature of Address (NoA) indicator, followed by another byte which 
contains the Numbering Plan Indicator (NPI), both of which are 
prefixed to a variable-length series of bytes that contains the 
digits of the telephone number in Binary Coded Decimal (BCD) format. 
In the calling party number case, the NPI’s byte also contains bit 
fields which represent the caller’s presentation preferences and the 
status of any call screening checks performed up until this point in 
the call. 


HGFEDCBA 
+-+-+-+-+-+-+-+-+ 
|] NoA | 
+-+-+-+-+-+-+-+-+ 


HGFEDCBA 
+-+-+-+-+-+-+-+-+ 
[ral NoA | 
+-+-+-+-+-+-+-+-+ 


| | NPI | spare | | NPI |Pri|sci| 


| 
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 
| dig...| dig 1 | | dig...| dig 1 | 
| er | #23 | 
| dig n | dig... | | dign | diaz] 
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 


ISUP format ISUP calling format 


ISUP numbering formats 


The NPI field is generally set to the value 'ISDN (Telephony) 
numbering plan (Recommendation E.164)’, but this does not mean that 
the digits which follow necessarily contain a country code; the NoA 
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field dictates whether the telephone number is in a national or 
international format. When the represented number is not designated 
to be in an international format, the NoA generally provides 
information specific to the national dialing plan - based on this 
information one can usually determine how to convert the number in 
question into an international format. Note that if the NPI contains 
a value other than ’ISDN numbering plan’, then the tel URL may not be 
suitable for carrying the address digits, and the handling for such 
calls is outside the scope of this document. 


1 ISUP format to tel URL mapping 


Based on the above, conversion from ISUP format to a tel URL is as 
follows. First, provided that the NPI field indicates that the 
telephone number format uses E.164, the NoA is consulted. If the NoA 
indicates that the number is an international number, then the 
telephone number digits SHOULD be appended unmodified to a ’tel:+’ 
string. If the NoA has the value 'national (significant) number’, 
then a country code MUST be prefixed to the telephone number digits 
before they are committed to a tel URL; if the gateway performing 
this conversion interconnects with switches homed to several 
different country codes, presumably the appropriate country code 
SHOULD be chosen based on the originating switch or trunk group. If 
the NoA has the value 'subscriber number’, both a country code and 
any other numbering components necessary for the numbering plan in 
question (such as area codes or city codes) MAY need to be added in 
order for the number to be internationally significant - however, 
such procedures vary greatly from country to country, and hence they 
cannot be specified in detail here. Only if a country or network- 
specific value is used for the NoA SHOULD a tel URL not include a ‘+’ 
sign; in these cases, gateways SHOULD simply copy the provided digits 
into the tel URL and append a ’user=phone’ parameter if a SIP URI 
format is used. Any non-standard or proprietary mechanisms used to 
communicate further context for the call in ISUP are outside the 
scope of this document. 


If a nationally-specific parameter is present that allows for the 
transmission of the calling party’s name (such as the Generic Name 
Parameter in ANSI), then generally, if presentation is not 
restricted, this information SHOULD be used to populate the display- 
name portion of the From field. 
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If ISUP calling format is being converted rather than ISUP format, 
then two additional pieces of information must be taken into account: 
presentation indicators and screening indicators. If the 
presentation indicators are set to 'presentation restricted’, then a 
special URI is created by the gateway which communicates to the far 
end that the caller's identity has been omitted. This URI SHOULD be 
a SIP URI with a display-name and username of 'Anonymous', e.g.: 


From: Anonymous <sip:anonymous@anonymous.invalid> 


For further information about privacy in SIP, see Section 5.7. 


If presentation is set to 'address unavailable’, then gateways should 
treat the IAM as if the CIN parameter was omitted. Screening 
indicators should not be translated, as they are only meaningful 
end-to-end. 


12.2 tel URL to ISUP format mapping 


Conversion from tel URLs to ISUP format is simpler. If the URI is in 
international format, then the gateway SHOULD consult the leading 
country code of the URI. If the country code is local to the gateway 
(the gateway has one or more trunks that point to switches which are 
homed to the country code in question), the gateway SHOULD set the 
NoA to reflect 'national (significant) number” and strip the country 
code from the URI before populating the digits field. If the country 
code is not local to the gateway, the gateway SHOULD set the NoA to 
“international number” and retain the country code. In either case 
the NPI MUST be set to ’ISDN numbering plan’. 


If the URI is not in international format, the gateway MAY attempt to 
treat the telephone number within the URI as if it were appropriate 
to its national or network-specific dialing plan; if doing so gives 
rise to internal gateway errors or the gateway does not support such 
procedures, then the gateway SHOULD respond with appropriate SIP 
status codes to express that the URI could not be understood (if the 
URI in question is the Request-URI, a 484). 


When converting from a tel URL to ISUP calling format, the procedure 
is identical to that described in the preceding paragraphs, but 
additionally, the presentation indicator SHOULD be set to 
‘presentation allowed’ and the screening indicator to 'network 
provided’, unless some service provider policy or user profile 
specifically disallows presentation. 
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Tx 


13: 


Other ISUP flavors 


Other flavors of ISUP different than ITU-T ISUP have different 
parameters and more features. Some of the parameters have more 
possible values and provide more information about the status of the 
call. 


The Circuit Query Message (COM) and Circuit Query Response (COR) are 
used in many ISUP variants. These messages have no analog in SIP, 
although receipt of a COR may Cause state reconciliation if the 
originating and destination switches have become desynchronized; as 
states are reconciled some calls may be terminated, which may cause 
SIP or ISUP messages to be sent (as described in Section 10). 


However, differences in the message flows are more important. In 
ANSI [11] ISUP, the CON message MUST NOT be sent; an ANM is sent 
instead (when no ACM has been sent before the call is answered). In 
call forwarding situations, CPGs MAY be sent before the ACM is sent. 
SAMs MUST NOT be sent; ’en-bloc’ signaling is always used. The ANSI 
Exit Message (EXM) SHOULD NOT result in any SIP signaling in 
gateways. ANSI also uses the Circuit Reservation Message (CRM) and 
Circuit Reservation Acknowledgment (CRA) as part of its interworking 
procedures - in the event that an MGC does receive a CRM, a CRA 
SHOULD be sent in return (in some implementations, transmissions of a 
CRA could conceivably be based on a resource reservation system) ; 
after a CRA is sent, the MGC SHOULD wait for a subsequent IAM and 
process it normally. Any further circuit reservation mechanism is 
outside the scope of this document. 


Although receipt of a Confusion (CFN) message is an indication of a 
protocol error, corresponding SIP messages SHOULD NOT be sent on 
receipt of a CEN - the CEN should be handled with ISUP-specific 
procedures by the gateway (usually by retransmission of the packet to 
which the CFN responded). Only if ISUP procedures fails repeatedly 
should this cause a SIP error condition (and call failure) to arise. 


In TTC ISUP CPGs MAY be sent before the ACM is sent. Messages such 
as a Charging Information Message (CHG) MAY be sent between ACM and 
ANM. ‘’En-bloc’ signaling is always used and there is no T9 timer. 


1 Guidelines for sending other ISUP messages 


Some ISUP variants send more messages than the ones described in this 
document. Therefore, some guidelines are provided here with regard 
to transport and mapping of these ISUP message. 


Camarillo, et. al. Standards Track [Page 58] 


RFC 3398 ISUP to SIP Mapping November 2002 


From the caller to the callee, other ISUP messages SHOULD be 
encapsulated (see [3]) inside INFO messages, even if the INVITE 
transaction is still not finished. Note that SIP does not ensure 
that INFO requests are delivered in order, and therefore in adverse 
network conditions an egress gateway might process INFOs out of 
order. This issue, however, does not represent an important problem 
since it is not likely to happen and its effects are negligible in 
most of the situations. The Information (INF) message and 
Information Response (INR) are examples of messages that should be 
encapsulated within an INFO. Gateway implementers might also 
consider building systems that wait for each INFO transaction to 
complete before initiating a new INFO transaction. 


From the callee to the caller, if a message is received by a gateway 
before the call has been answered (i.e., ANM is received) it SHOULD 
be encapsulated in an INFO, provided that this will not be the first 
SIP message sent in the backwards direction (in which case it SHOULD 
be encapsulated in a provisional 1xx response). Similarly a message 
which is received on the originating side (probably in response to an 
INR) before a 200 OK has been received by the gateway should be 
carried within an INFO. In order for this mechanism to function 
properly in the forward direction, any necessary Contact or To-tag 
must have appeared in a previous provisional response or the message 
might not be correctly routed to its destination. As such all SIP-T 
gateways MUST send all provisional responses with a Contact header 
and any necessary tags in order to enable proper routing of new 
requests issued before a final response has been received. When the 
INVITE transaction is finished INFO requests SHOULD also be used in 
this direction. 
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14. Acronyms 


ACK 
ACM 
ANM 
ANSI 
BLA 
BLO 
CGB 
CGBA 
CHG 
CON 
CPG 
CUG 
GRA 
GRS 
HLR 
IAM 
IETF 
IP 
ISDN 
ISUP 
ITU=T 


MG 
MGC 
MTP 
REL 
RES 
RLC 
RTP 
SCCP 
SG 
SIP 
SS7 
SUS 
TIC 
UAC 
UAS 
UDP 
VoIP 
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Acknowledgment 

Address Complete Message 

Answer Message 

American National Standards Institute 
Blocking ACK message 

Blocking Message 

Circuit Group Blocking Message 
Circuit Group Blocking ACK Message 
Charging Information Message 

Connect Message 

Call Progress Message 

Closed User Group 

Circuit Group Reset ACK Message 
Circuit Group Reset Message 

Home Location Register 

Initial Address Message 

Internet Engineering Task Force 
Internet Protocol 

Integrated Services Digital Network 
ISDN User Part 

International Telecommunication Union 
Telecommunication Standardization Sector 
Media Gateway 

Media Gateway Controller 

Message Transfer Part 

Release Message 

Resume Message 

Release Complete Message 

Real-time Transport Protocol 
Signaling Connection Control Part 
Signaling Gateway 

Session Initiation Protocol 

Signaling System No. 7 

Suspend Message 

Telecommunication Technology Committee 
User Agent Client 

User Agent Server 

User Datagram Protocol 

Voice over IP 


15. Security Considerations 


The translation of ISUP parameters into SIP headers may introduce 


2002 


some privacy and security concerns above and beyond those that have 
been identified for other functions of SIP-T [9A]. Merely securing 
for example, would not provide adequate privacy 


encapsulated ISUP, 
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for a user requesting presentation restriction if the Calling Party 
Number parameter is openly mapped to the From header. Section 12.2 
shows how SIP Privacy [9B] should be used for this function. Since 
the scope of SIP-ISUP mapping has been restricted to only those 
parameters that will be translated into the headers and fields used 
to route SIP requests, gateways consequently reveal through 
translation the minimum possible amount of information. 


A security analysis of ISUP is beyond the scope of this document. 
ISUP bridging across SIP is discussed more fully in [9A], but Section 
7.2.1.1 discusses processing the translated ISUP values in relation 
to any embedded ISUP in a request arriving at PSTN gateway. Lack of 
ISUP security analysis may pose some risks if embedded ISUP is 
blindly interpreted. Accordingly, gateways SHOULD NOT blindly trust 
embedded ISUP unless the request was strongly authenticated [9A], and 
the sender is trusted, e.g., is another MGC that is authorized to use 
ISUP over SIP in bridge mode. When requests are received from 
arbitrary end points, gateways SHOULD filter any received ISUP. In 
particular, only known-safe commands and parameters should be 
accepted or passed through. Filtering by deleting believed-to-be 
dangerous entries does not work well. 


In most respects, the information that is translated from ISUP to SIP 
has no special security requirements. In order for translated 
parameters to be used to route requests, they should be legible to 
intermediaries; end-to-end confidentiality of this data would be 
unnecessary and most likely detrimental. There are also numerous 
circumstances under which intermediaries can legitimately overwrite 
the values that have been provided by translation, and hence 
integrity over these headers is similarly not desirable. 


There are some concerns however that arise from the other direction 
of mapping, the mapping of SIP headers to ISUP parameters, which are 
enumerated in the following paragraphs. When end users dial numbers 
in the PSTN today, their selections populate the telephone number 
portion of the Called Party Number parameter, as well as the digit 
portions of the Carrier Identification Code and Transit Network 
Selection parameters of an ISUP IAM. Similarly, the tel URL and its 
optional parameters in the Request-URI of a SIP, which can be created 
directly by end users of a SIP device, map to those parameters at a 
gateway. However, in the PSTN, policy can prevent the user from 
dialing certain (invalid or restricted) numbers, or selecting certain 
carrier identification codes. Thus, gateway operators MAY wish to 
use corresponding policies to restrict the use of certain tel URLs, 
or tel URL parameters, when authorizing a call. 
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The fields relevant to number portability, which include in ANSI ISUP 
the LRN portion of the Generic Address Parameter and the 'M” bit of 
the Forward Call Indicators, are used to route calls in the PSTN. 
Since these fields are rendered as tel URL parameters in the SIP-ISUP 
mapping, users can set the value of these fields arbitrarily. 
Consequently, an end-user could change the end office to which a call 
would be routed (though if LRN value were chosen at random, it is 
more likely that it would prevent the call from being delivered 
altogether). The PSTN is relatively resilient to calls that have 
been misrouted on account of local number portability, however. In 
some networks, a REL message with some sort of "misrouted ported 
number" cause code is sent in the backwards direction when such a 
condition arises. Alternatively, the PSTN switch to which a call was 
misrouted can forward the call along to the proper switch after 
making its own number portability query - this is an interim number 
portability practice that is still common in most segments of the 
PSTN that support portability. It is not anticipated that end users 
will typically set these SIP fields, and the risks associated with 
allowing an adventurous or malicious user to set the LRN do not seem 
to be grave, but they should be noted by network operators. The 
limited degree to which SIP signaling contributes to the interworking 
indicators of the Forward Call Indicators and Backward Call Indicator 
parameters incurs no foreseeable risks. 


Some additional risks may result from the SIP response code to ISUP 
Cause Code parameter mapping. SIP user agents could conceivably 
respond to an INVITE from a gateway with any arbitrary SIP response 
code, and thus they can dictate (within the boundaries of the 
mappings supported by the gateway) the Q.850 cause code that will be 
sent by the gateway in the resulting REL message. Generally 
speaking, the manner in which a call is rejected is unlikely to 
provide any avenue for fraud or denial of service - to the best 
knowledge of the authors there is no cause code identified in this 
document that would signal that some call should not be billed, or 
that the network should take critical resources off-line. However, 
operators may want to scrutinize the set of cause codes that could be 
mapped from SIP response codes (listed in 7.2.6.1) to make sure that 
no undesirable network-specific behavior could result from operating 
a gateway supporting the recommended mappings. In some cases, 
operators MAY wish to implement gateway policies that use alternative 
mappings, perhaps selectively based on authorization data. 


If the Request-URI and the To header field of a request received at a 
gateway differ, Section 7.2.1.1 recommends that the To header (if it 
is a telephone number) should map to the Original Called Number 
parameter, and the Request-URI to the Called Party Number parameter. 
However, the user can, at the outset of a request, select a To header 
field value that differs from the Request-URI; these two field values 
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are not required to be the same. This essentially allows a user to 
set the ISUP Original Called Number parameter arbitrarily. Any 
applications that rely on the Original Called Number for settlement 
purposes could be affected by this mapping recommendation. It is 
anticipated that future SIP work in this space will arrive at a 
better general account of the re-targeting of SIP requests that may 
be applicable to the OCN mapping. 


The arbitrary population of the From header of requests by SIP user 
agents has some well-understood security implications for devices 
that rely on the From header as an accurate representation of the 
identity of the originator. Any gateway that intends to use the From 
header to populate the called party’s number parameter of an ISUP IAM 
message should authenticate the originator of the request and make 
sure that they are authorized to assert that calling number (or make 
use of some more secure method to ascertain the identity of the 
caller). Note that gateways, like all other SIP user agents, MUST 
support Digest authentication as described in [1]. 


There is another class of potential risk that is related to the cut- 
through of the backwards media path before the call is answered. 
Several practices described in this document recommend that a gateway 
signal an ACM when a called user agent returns a 18x provisional 
response code. At that time, backwards media will be cut through 
end-to-end in the ISUP network, and it is possible for the called 
user agent then to play arbitrary audio to the caller for an 
indefinite period of time before transmitting a final response (in 
the form of a 2xx or higher response code). There are conceivable 
respects in which this capability could be used illegitimately by the 
called user agent. It is also however a useful feature to allow 
progress tones and announcements to be played in the backwards 
direction in the ’ACM sent’ state (so that the caller won’t be billed 
for calls that don’t actually complete but for which failure 
conditions must be rendered to the user as in-band audio). In fact, 
ISUP commonly uses this backwards cut-through capability in order to 
pass tones and announcements relating to the status of a call when an 
ISUP network interworks with legacy networks that are not capable of 
expressing 0.850 cause codes. 


It is the contention of the authors that SIP introduces no risks with 
regard to backwards media that do not exist in Q.931-ISUP mapping, 
but gateways implementers MAY develop an optional mechanism (possibly 
something that could be configured by an operator) that would cut off 
such ’early media’ on a brief timer - it is unlikely that more than 
20 or 30 seconds of early media is necessary to convey status 
information about the call (see Section 7.2.6). A more conservative 
approach would be to never cut through backwards media in the gateway 
until a 2xx final response has been received, provided that the 
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gateway implements some way of prevent clipping of the initial media 
associated with the call. 


Unlike a traditional PSTN phone, a SIP user agent can launch multiple 
simultaneous requests in order to reach a particular resource. It 
would be trivial for a SIP user agent to launch 100 SIP requests at a 
100 port gateway, thereby tying up all of its ports. A malicious 
user could choose to launch requests to telephone numbers that are 
known never to answer, which would saturate these resources 
indefinitely and potentially without incurring any charges. Gateways 
therefore MAY support policies that restrict the number of 
simultaneous requests originating from the same authenticated source, 
or similar mechanisms to address this possible denial-of-service 
attack. 


16. IANA Considerations 
This document introduces no new considerations for IANA. 
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